Meddelande

Minska
No announcement yet.

Fundering kring TCP-protokollet.

Minska
X
 
  • Filter
  • Klockan
  • Show
Clear All
new posts

  • Fundering kring TCP-protokollet.

    Hej.

    Det slog mig för en stund sen, en rätt märklig sak.
    Eller, antagligen är svaret inte särskilt märkligt, utan märkligheten kommer nog av min egen ovisshet i saken.
    Nåväl. Till saken..

    Fundering #1)
    TCP-protokollet tycks ju klara av att hantera flera sessions på en samma port, ta exempelvis en httpd som svarar alla (åtskilliga remote ips, simultant aswell) på port 80, en ftpd/21, ircd/6667, ja, ni är nog med. Men, vad gäller TCP-connections som kommer att innefatta "flöde" tycks de flesta tillämpningar vilja ha en enskild port för varje "session". Skolexempel på detta ex DCC och PASV FTP. Vid DCC kan man ju t.ex. inte ha fler simultana dcc file transfers/chats än man har öppnat portar via NAT; same goes for passive FTP (at server-side), ställd port-range begränsar antalet anslutningar.

    Fundering #2)
    Som litet av en spin-off på #1, vid PORT ftp t.ex (fortf serverside-speaking), sägs det ju (rätta mig gärna) att ftpd:n alltid hookar sina utgående data-xfers till port 20. Säg då att ftpserver.com har två stycken pågående (active mode) x-fers, med vars olika remote IP, har den då jml. protokollet möjlighet att hooka upp _båda_ utgående PORT-xfers på interna port 20??

    Hur går allt ihop?
    Tacksam om någon insatt/kunnig kunde försöka förklara på ett - för en vanlig dödlig - någorlunda begripligt sätt!
    Tacksam för alla svar~

  • #2
    1. Nej, det går inte att ha flera sessions på samma port. Det som sker när du ansluter till en server är att den öppnar en ny port för dig. Det sker ju dock internt på servern så det är inget du märker, men det är därför den kan ha flera sessions samtidigt, för så fort som du fått din port så är ju den ursprungliga porten ledig igen för att ta emot en person till.

    2. Active mode betyder att ftp-servern ansluter till dig på port 20 hos dig. Internt tar den bara ett ledigt portnummer. Det funkar precis som att du kan vara uppkopplad till flera webservrar samtidigt trots att du ansluter till båda på port 80. Passive mode är att du upprättar en ytterligare förbindelse till ftp-servern på en annan port.

    Kommentera


    • #3
      tydal skrev: Visa inlägg
      1. Nej, det går inte att ha flera sessions på samma port. Det som sker när du ansluter till en server är att den öppnar en ny port för dig. Det sker ju dock internt på servern så det är inget du märker, men det är därför den kan ha flera sessions samtidigt, för så fort som du fått din port så är ju den ursprungliga porten ledig igen för att ta emot en person till.
      Nja, en webserver lyssnar bara på en port (80 eller 443 som standard) och kommunicerar bara via den. I brandväggen som sitter på webservern så öppnar man bara port 80 och ev. 443 (https) dom andra portarna är stängda.

      Det den håller reda på är vem som ansluter och från vilken port den ansluter från.

      Så det unika i ett tcp koppel är source-ip:source-port:dest-ip:dest-port på så sätt kan en webserver (eller smtp, pop3, imap ...) hålla ordning på vad som skall skickas vart.

      tydal skrev: Visa inlägg
      2. Active mode betyder att ftp-servern ansluter till dig på port 20 hos dig. Internt tar den bara ett ledigt portnummer. Det funkar precis som att du kan vara uppkopplad till flera webservrar samtidigt trots att du ansluter till båda på port 80. Passive mode är att du upprättar en ytterligare förbindelse till ftp-servern på en annan port.
      Aktiv mode innebär att klienten säger till servern att jag vill ha den här informationen/filen och skicka den till denna porten (slumpmässig och som ändras varje gång som data skickas) sedan kopplar ftp-server (från port 20) upp ett tcp-koppel mot den porten. Det är just detta som gör att ftp protokollet har så svårt för ointiligenta brandväggar.

      För mera (kanske bättre ) info om just ftp protokollet: http://www.webbhotellsguide.se/ftp/aktivtpassivt/

      Mera info om tcp protokollet: http://sv.wikipedia.org/wiki/Transmi...ntrol_Protocol
      So long and thanks for the fish.

      Tyvärr så har jag nu en person på min ignoreringslista. Personen ifråga höjer inte trivselfaktorn här, snarar tvärtom varför jag nu tackar för mig!

      Kommentera


      • #4
        Tack för era svar. Mjo, jag var faktiskt varse att tydal's definition på PORT ftp var lite sned. I detta sökande efter konsekvens och riktighet gällande vad som försiggår under motorhuven körde jag en app-monitor på min egen ftp daemon, och såg då att när man (PORT-)anslöt till den så öppnade den data xfers på port 20 internt(!), externt emot en port inom ramen för vad klienten angett i sina inställningar (de flesta ftp-klienter tillåter en att sätta sådan range).

        Nyckelbegreppet till det här som fortfarande grämmer mig kanske är termen "TCP-koppel" som du använde Gunnar. Vill du med det säga att (TCP-)tillämpningar som "grejjar" TCP-koppel är kapabla att hålla simultana sessions mot flera destination ip's på samma port, och där särskilja dem åt..? Isåfall utgår jag från att PORT-ftp's interna port (20) är av detta slag. Detta om vi säger att 192.168.0.2 & ~.3 båda ansluter till ~.1 och sedmera påbörjar PORT-transfer. Rimligtvis låter då servern sin [utgående] port 20 "delas" i det avseende att den används för utgående överföringsanslutning till såväl 192.168.0.2 som 192.168.0.3, eller?

        Det känns dock fortf lite virrigt. Om det är möjligt att skriva sådana "smarta" lösningar (TCP-koppel??), varför använder sig isf inte sånär som all mjukvara sig av den? Så att man exempelvis slipper ange en range om ~50 portar för PASV ftp eller DCC..? Or, what might I have missed out on?

        Kommentera


        • #5
          Kanske enklare ändå att bara berätta hur det funkar...

          För att göra något på nätverket behöver du en socket. All kommunikation sker alltid från en socket till en annan. Vill du ansluta till www.webforum.nu på port 80 så börjar din dator med att skapa en socket.

          På webForums webserver har de tidigare skapat en socket som använder en specifik port, nämligen port 80. Därefter har de sagt åt den att lyssna.

          Du säger nu åt din socket att ansluta till www.webforum.nu på port 80 och webForums lyssnande socket på port 80 kommer att upptäcka dig. Då accepterar den din anslutning, och det gör den genom att skapa en ny socket till dig. Därefter fortsätter den ursprungliga socketen hos webForum att lyssna efter andra besökare.

          Det är därför servern kan ha flera anslutningar igång samtidigt som har kommit in genom samma port, alla har varsin socket.

          Men som Gunnar säger, det som håller isär förbindelserna är alltså source-ip:source-port:dest-ip:dest-port som måste vara unikt. Så om det är så att när ftp-servern upprättar en förbindelse mot dig, att den binder sin socket till port 20 (har aldrig skrivit en ftp-server så jag hade inte full kolla på det), ja då har du ju source-ip:source-port:dest-ip konstant för varje förbindelse från servern till dig, och det enda som kan variera är dest-port, alltså den port du måste öppna i brandväggen. Kanske det förklarar varför du måste öppna fler portar?

          Kommentera


          • #6
            Kanske. Jag lyckades iaf hitta två labbterminaler nu, så jag kunde få svart på vitt. Har FTPD på .1 och har sedan anslutit från .2 och .3 och påbörjat en långdragen filöverföring á PORT. Kollade sedan i app-monitorn hur situationen såg ut för filezillaserver.exe, och ja visst, servern ser mkt riktigt ut att använda [sin egna] port 20 för båda anslutningarna, fast var och en för sig. Och ja, ip särskiljer ju dem, så därför torde det ju isf (jml. detta "source-ip:source-port:dest-i") funka. Fast vad händer om jag öppnar ytterligare en connection från ie .2 el .3 och påbörjar ännu en PORT-överföring. Då särskilj.. provade just.. fast kom på att destort särskiljer ju fortfarande, för visst, den öppnade även sin "dupade" connection (från samma IP) på egna 20 ut, fast en annan rnd>1023 inåt. Humma, ska ligga ikväll och försöka klura ut varför PASV överföringar ändock kräver av FTP-servern att enskild port öppnas för varje x-fer som ska gå att hållas uppe simultant, för den biten är fortf lite vag för mig. Men vi är på väg nånstans, sakta men säkert..

            Kommentera


            • #7
              Gew skrev: Visa inlägg
              Nyckelbegreppem du använde Gunnar. Vill du med det säga att (TCP-)tillämpningar som "grejjar" TCP-koppel är kapabla att hålla simultana sessions mot flera destination ip's på samma port, och där särskilja dem åt..? Isåfall utgår jag från att PORT-ftp's interna port (20) är av detta slag. Detta om vi säger att 192.168.0.2 & ~.3 båda ansluter till ~.1 och sedmera påbörjar PORT-transfer. Rimligtvis låter då servern sin [utgående] port 20 "delas" i det avseende att den används för utgående överföringsanslutning till såväl 192.168.0.2 som 192.168.0.3, eller?
              Ja, så länge "quadruppeln" sourceip:sourceport:destip:destport är unik så kan ett program hålla isär vad som skickas vart.

              Ett enkelt test är att ge kommandot "netstat -a" då får man en hel del information om vilka tcp/udp portar som det ligger program och lyssnar på och vilka tcp och udp koppel som är uppe och vilken status dom har.
              So long and thanks for the fish.

              Tyvärr så har jag nu en person på min ignoreringslista. Personen ifråga höjer inte trivselfaktorn här, snarar tvärtom varför jag nu tackar för mig!

              Kommentera


              • #8
                Lysande!

                Så bara en liten grej som kommit av allt detta, och som jag f.ö. frågat mig själv i många år. Är det så att:

                #1) det går 255 IP's(!) per oktat; sedmera 65535 portar(!) per sådan IP; sedmera <to_me_unknown_integer> socketar per sådan IPort.

                ELLER

                Är "socketen" per se ett slags produkt av formulan IPort..?

                Kommentera


                • #9
                  En socket är internt i tcp/ip stacken.

                  Man kommer att ha flera socketar som används för en port.

                  Google efter "simple tcp server" så får du flera exempel hur det fungerar.

                  Men principen är att man skapar en socket som sedan lyssnar på en port (ex. 80) för varje ny anslutning så skapas/clonas socketen till en ny som sedan servern använder för att kommunicera med klienten, den första socketen finns kvar och fortsätter att lysna efter nya anslutningar. Så server har en socket per anslutning men det är forfarande samma port på servern som kommunikationen sker igenom, tcp/ip stacken håller reda på "quadrupeln",
                  So long and thanks for the fish.

                  Tyvärr så har jag nu en person på min ignoreringslista. Personen ifråga höjer inte trivselfaktorn här, snarar tvärtom varför jag nu tackar för mig!

                  Kommentera


                  • #10
                    Begränsningen är att det bara går att lyssna med en socket per port.

                    Kommentera


                    • #11
                      GunnarD skrev: Visa inlägg
                      En socket är internt i tcp/ip stacken.

                      Man kommer att ha flera socketar som används för en port.

                      Google efter "simple tcp server" så får du flera exempel hur det fungerar.

                      Men principen är att man skapar en socket som sedan lyssnar på en port (ex. 80) för varje ny anslutning så skapas/clonas socketen till en ny som sedan servern använder för att kommunicera med klienten, den första socketen finns kvar och fortsätter att lysna efter nya anslutningar. Så server har en socket per anslutning men det är forfarande samma port på servern som kommunikationen sker igenom, tcp/ip stacken håller reda på "quadrupeln",
                      Ah, jag börjar förstå. Vidare då, om PASV ftp sägs ju (para-citerar från nånstans jag läste på nätet) "the only real security-wise downside with passive ftp is that you need to open a wider port range on the server-side." Det som "kortsluter" hela fundamentalismen i detta för mig i mitt huvud är varför de isf inte gör en enkel(?) inplementation så att PASV ftp alltid sätter samma listen-port för data-transfers, när detta jml. "quadrupeln" tycks möjligt, och inte en range om - vanligtvis - cirkus 50 portar..? Om någon av er nu skulle droppa som svar "det beror helt enkelt på att FTP är ett urgammalt protokoll och att quadrupeln inte var tillräckligt utvecklad i dess begynnelse och således blev det som det blev, och man kan inte rucka på hela grunden för ett protokoll. Hade FTP-protokollet uppfunnits idag så hade det med stor sannolikhet lyssnat efter - samtliga - passiva data-connection på en och samma port" så skulle jag få frid och ro och kanske lyckas släppa allt och gå vidare!

                      Kommentera


                      • #12
                        Tyvärr är det inte så enkelt som att FTP är gammalt, för det här med TCP och "quadrupel" är ju äldre...

                        Jag tror (eftersom jag inte skrivit någon ftp-server, och inte ftp-klient heller för den delen) att det har med identifiering att göra. När klienten ska öppna en ny förbindelse för data så sker ju det med en ny port på klientsidan och då är det ju inte längre samma source-port. Om ftp-servern och klienten via den redan upprättade förbindelsen har kommit överens om vilken dest-port som ska användas så förstår ju ftp-servern vem det är som ansluter.

                        Skulle alla ansluta på samma dataport så skulle inte ftp-servern veta vem som var vem, utan någon slags identifiering skulle behövas på dataporten innan dataöverförngen startar, och kanske har man bestämt att man vill att all kontroll ska ske på kontrollkanalen och inte på datakanalen.

                        Kommentera


                        • #13
                          Ditt svar var tillfredstälande, eg. de facto att en port / session i t.ex. FTP/DCC är ett överlagt/medvetet val av utvecklarna, hellre än en begränsning i protokollet per se, spräckte mitt grubbleri. Du lyckades dessutom bra i att på ett begripligt sätt förklara/beskriva [den antagna] bakgrunden till att ie. FTP väljer att göra på detta vis (identification issuet). Tack!

                          Kommentera

                          Working...
                          X