Frågan#1
Vad är det för skilnad på TCP & UDP?
TCP & UDP!
15 svar · 565 visningar · startad av Akerlundh
Okej!
Men nu är det som så här att jag har DC hub oo jag undrar om jag ska ha båda portarna öppna eller bara ena?
DC skickar både TCP-paket och UDP-paket ( Tar emot också för den delen... ), men jag kan inte svara på om det sker via samma port eller inte. Jag skulle gissa på att applikationen inte använder samma port för TCP och UDP.
DC använder samma portnummer både för UDP och TCP. Det innebär inte att det är samma port, UDP portarna är skilda från TCP portarna.
UDP är inte oberoende av nätbelastningen så som det stod i inlägget SirPeter hänvisade till.
Man kan göra följande jämförelse för att förklara vad det är och hur dom fungerar:
TCP kan man jämföra med telefoni, man får en "garanterad" koppling mellan avsändaren och mottagaren, evetuella fel i överföringen rättas av "nätverket".
UDP kan man jämföra med radiotrafik, man skickar ut någonting och hoppas att mottagaren får det. För att hålla koll på att "trafiken" kommit fram så får man hålla med "kom" och "klart slut" för att signalera till mottagaren att man är klar och väntar på svar eller att man skall sluta.
Iom att man i UDP fallet har flyttat handskakningen och felhanteringen ifrån "nätverket" till "applikationen" så krävs det mindre av datorn att hantera UDP än TCP vilket gör att man använder UDP för mätningar eftersom det kräver mindre av datorerna och nätverksutrustningen och ger "bättre" värden.
UDP - User Datagram Protocol
TCP - Transport/Transmission Control Protocol
TCP tillhandahåller en upprättad förbindelse mellan två noder i ett nätverk, och kontrollerar även paketförmedlingen. Används vid t.ex. surfning, och liknande, där det är viktigt att paketen kommer fram och i rätt ordning.
UDP är ett förbindelselöst protokoll, men att jämföra med radiotrafik vet jag inte... Det är ju inte "rakt ut i etern" så att säga - utan det har en adress - ett IP - som det ska levereras till. Däremot finns det ingen garanti för att alla paket kommer fram, eller att de kommer fram i rätt ordning. Därför lämpar sig UDP vid mediavisningar eller vid spel, där gamla eller felaktiga paket inte längre är intressanta, för man vill ju inte veta vad som redan hänt - man vill ju veta vad som händer. :)
UDP kontrollerar inte heller mängden på det som skickas ut, så att säga att det kräver mindre håller inte alltid i alla sammanhang. Ett nätverk kan lätt bli överbelastat och därmed förstöra för andra användare.
UDP lämpar sig bra för spel m.m då det lämnar åt applikationen att handhava paketen, vilket gör det lite enklare att själv bygga, ett för applikationen lämpligt protokoll om du inte TCP duger (vilket det faktiskt inte alltid gör iom en design om att alla paket ska fram, före en design om hur fort det ska gå).
Applikationer som 'floodar' ned ett nätverk är taskigt designade i sig och det är inte UDPs fel. :)
Absolut, men det uppkommer vid paketförmedling á la UDP, och är inte vanligt med TCP. Det är självklart pga applikationerna, men protokollet i sig innehåller inte någon mängdbegränsning på data som skickas - vilket kan orsaka överbelastning. För att formulera mig bättre. :)
Visst. Och samtidigt är det (som jag fattat det) TCP:ns flödeskontroll i sig som gör att UDP är att föredra då man vill ha en jämn ström data (video m.m) iom att med TCP så maxas flödet till att gå över gränsen, för att sen bara börja om => ryckigt vid sammanhängande data. Man kan ju bygga på fel- och flödeskontroller på UDP, men med lite större cache (buckets) för att anpassa kommunikationen till behovet på ett lämpligare sätt.
För det mesta duger TCP, men UDP ger lite mer möjligheter - under ansvar.
Och SPiN borde få sitt svar "accepterat som slutgiltigt svar" då det var en mycket bra och korrekt förklaring... :)
SPiN skrev:
UDP är ett förbindelselöst protokoll, men att jämföra med radiotrafik vet jag inte... Det är ju inte "rakt ut i etern" så att säga - utan det har en adress - ett IP - som det ska levereras till.
Självklart, men du har inte handskaknings och felhanteringen i protokollstacket som med TCP, utan det är mera: Skicka det här paketet till den här mottagaren men den verifierar inte att det finns någon mottagare eller att mottagaren har fått paketet utan detta sker på "applikations" nivån (i min jämförelse samma som "kom" och "klart slut" i radiokommunikation).
GunnarD, ok. Jag uppfattade det mer som att man bara skickade ut data och vem som helst fick lyssna på den. :)
mattiasnordin> Nja, jag svarade ju egentligen inte på frågan om hur man konfigurerar brandväggen för DC, utan mer en allmän förklaring över UDP och TCP. Men tack ändå. :r :)
Det vanligaste är kanske att man jämför UDP med post? (Om man nu jämför TCP med telefoni.)
Ett brev har ju en mottagare och en avsändare, men avsändaren har ingen direkt möjlighet att avgöra när eller om brevet kommit fram till mottagaren. (Radiotrafik blir isåf UDP-broadcast.)
SPiN skrev:
Absolut, men det uppkommer vid paketförmedling á la UDP, och är inte vanligt med TCP. Det är självklart pga applikationerna, men protokollet i sig innehåller inte någon mängdbegränsning på data som skickas - vilket kan orsaka överbelastning. För att formulera mig bättre. :)
Jag ser inte direkt hur UDP skulle kunna överbelasta ett nätverk pga av att det inte ha någon "mängdbegränsning"? Paket storleken är ju beroende på MTU (Maximum Transmission Unit - 1500 för Ethernet nätverk). Både TCP och UDP kan överbelasta nätverk med illvilliga applikationer.
PeW skrev:
Visst. Och samtidigt är det (som jag fattat det) TCP:ns flödeskontroll i sig som gör att UDP är att föredra då man vill ha en jämn ström data (video m.m) iom att med TCP så maxas flödet till att gå över gränsen, för att sen bara börja om => ryckigt vid sammanhängande data. Man kan ju bygga på fel- och flödeskontroller på UDP, men med lite större cache (buckets) för att anpassa kommunikationen till behovet på ett lämpligare sätt.
För det mesta duger TCP, men UDP ger lite mer möjligheter - under ansvar.
Video och media skickas effektivast med UDP. Tänk dig att du ser en film online - UDP använder inte en kontrollmekanism samtidigt som du inte ser varje enskild filmruta. Det gör alltså inget om inte alla paketen kommer fram (eller kommer i fel ordning) - du kommer knappt märka av det. Skulle filmen skickas med TCP måste varje paket kontrolleras att det kommit fram, ordningen på paketen måste säkerställas och att inga dubletter finns etc.
D3VaST8D skrev:
PeW skrev:
Visst. Och samtidigt är det (som jag fattat det) TCP:ns flödeskontroll i sig som gör att UDP är att föredra då man vill ha en jämn ström data (video m.m) iom att med TCP så maxas flödet till att gå över gränsen, för att sen bara börja om => ryckigt vid sammanhängande data. Man kan ju bygga på fel- och flödeskontroller på UDP, men med lite större cache (buckets) för att anpassa kommunikationen till behovet på ett lämpligare sätt.
För det mesta duger TCP, men UDP ger lite mer möjligheter - under ansvar.Video och media skickas effektivast med UDP. Tänk dig att du ser en film online - UDP använder inte en kontrollmekanism samtidigt som du inte ser varje enskild filmruta. Det gör alltså inget om inte alla paketen kommer fram (eller kommer i fel ordning) - du kommer knappt märka av det. Skulle filmen skickas med TCP måste varje paket kontrolleras att det kommit fram, ordningen på paketen måste säkerställas och att inga dubletter finns etc.
Jepp, det var ju faktiskt det jag skrev fast med andra ord :)
Men även i en störningsfri kanal där alla paket kommer fram hela och i rätt ordning skulle TCP vara olämpligt för video iom dess flödeskontroll / stockningsprotokoll (som iofs bygger på att acken kommer när de ska vilka de inte gör när 'hastighets'-gränsen passerats).
Med UDP flyttas kontrollen upp till applikationslagret så man kan ju anpassa efter behovet.