Förbättrad TCP/IP

Nej?

Naturligtvis går det att ta fram ett tekniskt bättre protokoll men det gäller att få med tillräckligt många så det blir standard också.
Tekniskt möjligt men ekonomiskt osannolikt är nog bästa svaret på frågan.

Till att börja med få alla att komma över till IPv6 ?

Spännande! Vad tycker du är dåligt med TCP/IP?

Ja. Det finns en drös med TCP-substitut. Men att lägga IP på hyllan blir betydligt värre så länge man inte tunnlar över IP (dumt om man vill undvika IP) eller om man får ett L2-nät som täcker det man vill kommunicera med (som kanske ändå tunnlas över IP om man inte har koll över vad tredjepartsoperatörer gör).

Eller en arkitektur som lät enheter kommunicera utan något medium (kabel, wifi o.s.v.)
Oerhört häftigt, men också omöjligt. Precis som att "Eliminiera spårning helt". En förutsättning för att en router ska kunna vidarebefodra ett paket är att den vet var det ska vidarebefodras.

Varför inte?

Det finns ju redan substitut, som sagt...

Jobbar man inte på någon ersättare för tcp i trådlösa nätverk? Eller har man grusat de planerna?

För att det är inte realistiskt på en global skala att gå över till ett helt annat protokoll, de nuvarande kommer fortfarande finnas globalt på internet och hur det fungerar, för världen kommer inte inom kort framtid byta ut dyr hårdvara som stödjer ett nytt protokoll. Givetvis så skulle man kunna använda ett annat protokoll, det finns t.ex variationer på tcp, udp etc som används specifikt för datacenter miljöer, men hur ip och tcp/udp fungerar ligger fortfarande kvar.

IPv6 har funnits sedan någon gång på 90-talet och fortfarande inte implementerat i världen och det är bara till viss dess adressering och inte direkt ett helt nytt kommunikations protokoll.

Så nej, vi kommer nog aldrig se ett helt nytt protokoll som kommer att användas globalt, sedan så när det gäller mindre nätverk så finns det inte sådan stor anledning att ens gå över till nåt annat. Även t.ex stadsnät eller öppna nät i Sverige är layer-2 switchade nät över fiber länkar, du använder inte ens tcp och ip till större delen, även om du skickar trafik från typ skåne till stockholm som sedan routas ut på internet.

Ja, att det är svårt att byta nätverksprotokoll vet vi ju, men du skrev att det inte skulle gå, vilket bevisligen är fel. Vi kommer tvingas dit vare sig vi vill eller inte nu när varenda dammpartikel ska kopplas upp till nätet.

ATt tekniskt sätt skapa en standard som hade kunnat vara bättre är nog inga problem. Men om man ser till de summor som redan idag är investerade i TCP/IP nät och den mängd hårdvara som existerar så skulle det nog vara väldigt svårt att få till en ändring.

För lokala nät hade man säkert kunnat göra detta då det är mycket enklare att genomföra och inte är i närheten att lika komplext som ett helt teknikskifte för hela internet. Kanske kunde man börja så, sedan släppa produkter som klarade båda standarderna och kunde skicka mellan två punkter på det effektivaste sättet och när allt (om en massa år) bestod av denna typ av enheter hade man kunnat switcha till att köra det nya protokollet fullt ut. Men det hade äändå inte varit någon lätt sak att få till stånd.

Använd parental controls istället.

Det blir lite fel när man skriver tcp/ip.
IP är det överliggande protokollet som bara ansvarar för att skicka paketen från en enhet till en annan (med hjälp av ARP/ICMP och sådant).
Sedan har vi protokoll som TCP och UDP osv som ligger på en nivå högre och transporteras inuti IP.

Jag ser inget problem med om vi använder IPv4 eller IPv6 egentligen, utan är det något protokoll som borde gå att ordentligt förbättra så är det TCP. Man har i efterhand fått lägga till grejor som utökat "fönster" så kallat window scaling då man initialt inte förutsåg de hastigheter vi har idag då 65k data är väldigt lite. Man har också Selective ACK av mer eller mindre samma orsak. Dvs, det finns mycket som man gjorde i internets barndom som inte riktigt håller idag utan gaffatejp.

Sedan finns det en hel del saker på laget 5-7 som är tokiga. FTP, tFTP och många andra tidiga protokoll är fullständigt horribelt skriva exempelvis.

Nåja, för den som vill läsa på lite kring TCP/IP så rekommenderar jag att man lär sig lite om OSI-modellen:
http://sv.wikipedia.org/wiki/OSI-modellen

IPX/SPX hade kanske varit grejen om det bara hade kunnat routas riktigt bekvämt.

Tyvärr finns det nog massor med bra saker som blivit ratade för att det redan finns en standard, låt vara att den är riktigt illa.

Är vi inne på det där med Selective ACK och windows scaling så är det såhär.

I TCP finns det ett fönster med 65535 bytes som man kan skicka utan att motstående sidan skickat ett ACK (Acknowledge, dvs bekräftelse på att det kommit fram). Vid långa avstånd (latency) och hög bandbredd innebär det att prestandan kommer att lida oerhört. Lösningen heter window scaling, som innebär att man med en faktor dubblerar fönstret. Dvs, värdet två innebär dubbelt så stort fönster och därmed dubbelt så mycket data som kan skickas innan andra sidan måste skicka sitt ACK. Problemet är dock att brandväggar på internet måste i sådana fall också utöka sina TCP-fönster för att kunna skanna av skadlig kod och att hålla reda på att paket kommer i rätt ordning. Brandväggen måste kunna sätta ihop hela fönstret för att kunna se om det är en attack, för annars är det bara att dela upp ett virus/en sql injection osv på flera olika paket.

ACK är korkat idag. Då kan du bara ACKa upp till så mycket data du tagit emot. Skickas tio paket och paket nummer 2 försvinner (packet loss) så kan motstående sida bara skicka ACK efter paket nummer 1. Paket 3-10 som faktiskt kommit fram måste skickas om. Därmed blir det givetvis oerhört mycket som kan behöva skickas om helt i onödan. Med Selective ACK så kan man istället skicka ett ACK som innebär att man bekräftar exakt vilka paket man tagit emot och endast paket nummer 2 behöver skickas om. Brandväggar har i många fall inte möjligheten att tolka selective ack korrekt och därför har man ingen nytta av den smarta funktionen.

Sedan finns det problem med reglering av hastighet. TCP ska automatiskt känna utav om det är packet loss eller om det går långsamt. Det fungerar sådär men fundamentalt blir det tokfel när man kör TCP inuti TCP med packet loss. Dvs, remote desktop inuti SSL exempelvis. Det finns felkorrigering i TCP-protokollet och att då ha både den yttre och den inre TCP som kan båda motverka varandra gör att det kan bli helt värdelöst så fort man har det minsta packet loss.
http://sites.inka.de/~W1011/devel/tcp-tcp.html (Gammal, men precis lika aktuell fortfarande).

Som ni förstår finns det utrymme för att tänka ut ett bättre protokoll än TCP som hanterar att alla paket kommer fram, som gör det enkelt att reglera hastighet, som gör det möjligt för brandväggar att scanna trafik osv.