Neden 3 yollu el sıkışmasına ihtiyacımız var? Neden sadece 2 yönlü değil?

TCP 3 yollu el sıkışma şöyle çalışır:

Client ------SYN-----> Server
Client <---ACK/SYN---- Server
Client ------ACK-----> Server

Neden sadece bu değil?

Client ------SYN-----> Server
Client <-----ACK------ Server

El sıkışmasını gerçekte ne yaptığına ayırın.

TCP’de, iki taraf bir Sıra numarası kullanarak ne gönderdiklerini takip eder. Etkili, gönderilen her şeyin çalışan bir bayt sayısı olmasıyla sonuçlanır. Alıcı taraf, karşı tarafın ne aldığını kabul etmek için sıra numarasını kullanabilir.

Ancak dizi numarası 0'dan başlamaz. Rastgele seçilen bir değer olan ISN'den (İlk Sıra Numarası) başlar. Ve TCP iki yönlü bir iletişim olduğundan, her iki taraf da "konuşabilir" ve bu nedenle her ikisi de rastgele başlangıç ​​Sıra Numarası olarak bir ISN üretmelidir. Bu da iki tarafın da diğer tarafa başlangıçtaki ISN'lerini bildirmeleri gerektiği anlamına gelir.

Öyleyse, Alice ile Bob arasındaki bir TCP sohbetinin başlaması için bu olay dizisiyle bitiyorsunuz:

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

Dikkat, dört olay gerçekleşiyor:

1. Alice bir ISN seçer ve onu Bob ile senkronize eder.
2. Bob AC ISN'yi tanıyor .
3. Bob bir ISN seçer ve onu Alice ile senkronize eder.
4. Alice AC ISN'yi tanıdı .

Gerçekte, aslında ortadaki iki olay (# 2 ve # 3) aynı pakette gerçekleşiyor. Bir paketi yapan SYNveya ACKbasitçe, her TCP başlığının içinde açılmış veya kapatılmış bir ikili bayrak olduğundan, bu bayrakların her ikisinin de aynı pakette etkinleştirilmesini engelleyen hiçbir şey yoktur. Böylece üç yollu el sıkışma sona erer:

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK     

Her iki yönde de "SYN" ve "ACK" olmak üzere iki örneğe dikkat edin.

Öyleyse sorunuza geri dönelim, neden sadece iki yönlü bir el sıkışma kullanmıyorsunuz? Kısa cevap, iki yönlü el sıkışmasının yalnızca bir tarafın ISN kurmasına ve diğer tarafın bunu onaylamasına izin vermesidir. Bu, yalnızca bir tarafın veri gönderebileceği anlamına gelir.

Ancak TCP, iki yönlü bir iletişim protokolüdür; bu, her iki ucun da güvenilir bir şekilde veri gönderebilmesi gerektiği anlamına gelir. Her iki tarafın da bir ISN kurması ve her iki tarafın da diğerinin ISN'sini kabul etmesi gerekir.

Sonuç olarak, elinizde olan şey, iki yönlü el sıkışmasının tam olarak sizin tarifinizdir, ancak her yöne . Dolayısıyla, dört olay meydana geliyor. Ve yine, ortadaki iki bayrak aynı pakette olur. Gibi üç paket tam bir TCP bağlantı başlatma işleminde yer almaktadır.

Her iki tarafın gerekir, çünkü üç yönlü el sıkışma gereklidir syn chronize kendi iletimi sırasında kullanılan kendi kademeli bir dizi numaralarını. Bunun için, her biri (ki bu da) bir rastgele değer olarak ayarlanmış, bir sıra numarası bir SYN gönderir n o olduğu, bildirim ayarlanmış bir sıra numarası ile bir ACK bölümü yoluyla, diğer tarafın nowledged n + 1 .

Bağlantının çalışması için, her bir tarafın diğer tarafa paket gönderebildiğini doğrulaması gerekir. Diğer tarafa bir paket aldığınızdan emin olmanın tek yolu, onlardan bir paket almaktır, tanımı gereği, gönderdiğiniz paket geçmeden gönderilemez . TCP esasen bunun için mesajların iki çeşit kullanır: SYN ve (SYN SYN sahasına girdi kanıtlamak için, içinden alır sonra ancak gönderilen alır) ACK (bu paket sayesinde var kanıt istemek için). Aslında üçüncü tür bir mesaj var, ancak bir dakika sonra buna varacağız.

Bağlantı başlamadan önce, iki taraf da diğeriyle ilgili hiçbir şey bilmiyor. İstemci, iletilerinin ulaşabileceğinin kanıtını istemek için sunucuya bir SYN paketi gönderir . Bu her iki kişiye de bir şey söylemiyor, ancak el sıkışmasının ilk adımı.

SYN geçerse, sunucu müşterinin kendisine paket gönderebileceğini bilir, çünkü tam olarak gerçekleşti. Ancak bu sunucunun paketleri geri gönderebileceğini kanıtlamaz: istemciler birçok nedenden dolayı SYN'ler gönderebilir . Bu yüzden sunucunun istemciye iki ileti göndermesi gerekir: bir ACK (SYN'nin geçtiğini kanıtlamak için) ve bir SYN (kendi ACK'sini istemek için). Ağ trafiğini azaltacaksanız, TCP bu iki mesajı bir-bir SYN-ACK mesajında ​​birleştirir. Bu, el sıkışmasının ikinci adımıdır.

Bir SYN-ACK bir ACK olduğundan, istemci artık sunucuya paket gönderebileceğinden emindir. Bir SYN-ACK bir SYN olduğundan, sunucunun bu mesajın geçtiğinin kanıtı istediğini de bilir. Bu yüzden bir ACK'yı geri gönderir: bu sefer sadece düz bir ACK, çünkü paketlerinin geçebileceği bir kanıtı olması gerekmiyor. Bu el sıkışma son adımdır: istemcisi artık paketler her iki yöne gidebilir biliyor ve sunucu olduğunu hemen (o bildiği için ACK geçeceği) bu anlamaya.

Bu ACK geçtikten sonra, sunucu artık müşteriye paket gönderebileceğini biliyor . Ayrıca müşterinin bunu bildiğini de bilir, böylece hemen veri göndermeye başlayabilir. El sıkışma tamamlandı. İyi bir kanalımız var.

Kesin konuşursak, iyi bir kanalımız olduğundan emin olamayız . Sırf bu paketler dizisinin içinden geçmesi, diğerlerinin de yapacağı kesin garantiyi vermez . Sonsuz sayıda SYN ve ACK göndermeden ve hiçbir şey yapamayacağımızı ispatlayamayız, bu yüzden bu gerçekten pratik bir seçenek değildir. Ancak pratikte, üç adımın çoğu amaç için yeterince iyi olduğu ortaya çıktı .

Aslında, 3 yollu bir el sıkışma bir TCP bağlantısı kurmanın tek yolu değildir. Eşzamanlı SYN değişimine de izin verilir: http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm

Bir çeşit çift yönlü 2 el sıkışma olarak görülebilir.

TCP bağlantısı çift yönlüdür. Bunun anlamı, aslında bir çift yönlü bağlantı olduğu. Başlatıcı SYN gönderir, cevaplayıcı ACK gönderir: bir tek taraflı bağlantı başlar. "Sonra" yanıtlayıcı SYN'yi gönderir, başlatıcı ACK'yı gönderir: başka bir tek taraflı bağlantı başlar. İki tek yönlü bağlantı bir çift yönlü TCP oturumu oluşturur, katılıyorum? Yani mantıksal olarak dört adım var; ancak SYN ve ACK bayrakları TCP başlığının farklı "alanları" olduğundan, eşzamanlı olarak ayarlanabilirler - ikinci ve üçüncü adımlar (dördün) birleştirilir, teknik olarak üç paket alışverişi vardır. Her bir tek yönlü (yarım) bağlantı, önerdiğiniz gibi 2 yönlü değişim kullanır.

Sunucu ve İstemci bir bağlantı oluşturmak istiyorsa, dört şeyi onaylamaları gerekir:

1. Sunucunun müşteriden paket alabildiğini doğrulaması gerekiyor.

2. Müşterinin Sunucudan paket alabildiğini doğrulaması gerekir.

3. Müşterinin bir şeyi onaylaması gerekir: Sunucu İstemciden paket alabilir

4. Sunucunun bir şeyi onaylaması gerekir: İstemci Sunucudan paket alabilir

Sonra Client ------SYN-----> Server, kural 1 onaylanır.

Sonra Client <---ACK/SYN---- Server, kural 2 ve 3 onaylanır.

Bu nedenle, 4. kuralı onaylamak için üçüncü bir paket gerekir.

Hiç gerekli değil. Kısa bir mesajın yalnızca start + mesajı içeren sunucuya bir paket, bir onay mesajı geri kabul etmesi gerektiği açıktır.

Önceki cevaplar sadece rasgele sıra numaralarına vb. İhtiyaç duyulmadan ilk önce sistemi tarif eder. Asıl soru, TCP'nin kendi tasarımıyla ilgiliydi - tabii ki TCP protokolünü kullanıyorsanız, o zaman protokol olduğu için üç mesaja ihtiyacınız var. Fakat neden TCP ilk olarak bu şekilde tasarlandı?

Bence asıl fikir, müşteriler ve sunucular arasında bir fark olmadığıydı. Her ikisi de diğerinin limanlarını iki yönlü bir şekilde biliyordu ve ikisi de sohbeti başlatabilirdi. Ve bu Syns vb gerekli.

Fakat bu, elbette, bugün nasıl kullanıldığı değildir. Sunucu bilinen bir bağlantı noktasını dinler ve "kabul eder" yapar ve istemci bağlantı noktası numarası geçicidir. Normal işletim sistemlerinde aynı müşteri port numarasından bir başkasına bir istek göndermesi için "kabul et" bekleyen bir sunucunun mümkün olduğunu bile sanmıyorum .

(Bunun, bugün hiç yapılmayan, bağlantının iki yönlü başlatılmasıyla ilgili olduğunu unutmayın. Bu, bir kez kurulan bir bağlantı üzerinden iki yönlü mesajların gönderilmesinden oldukça farklıdır.)

TCP verimsizliği etrafında çalışmak için, aynı bağlantıyı birden fazla istek için yeniden kullanabilen HTTP 1.1 gibi protokoller kullanırız ve böylece ilk başta gerekli olmayan TCP el sıkışmasından kaçınırız.

Ancak Http 1.1 nispeten yeni. Ve SSL / TLS, PKI algoritmalarının maliyeti nedeniyle, oturumu baştan yeniden kullanmanın bir yoluna ihtiyaç duyuyordu. Bu protokol, TCP'nin üstünde çalışan Http 1.1'in üzerinde çalışan kendi oturum yeniden kullanma mekanizmasını içerir.

Yazılım böyledir. Bir araya geldiğinde kabul edilebilir bir sonuç veren çamurlardaki şekerlemeler.

Eddie'nin cevabını okuduktan sonra (doğru olarak kabul edildi), neden hala ilk sunucunun her iki ISN'yi rastgele sayılarla atayamayacağı ve ikincisi de bunu kabul edemediği sorusu vardır. 3 yönlü el sıkışma kullanmanın asıl nedeni, yarı bağlantıdan kaçınmaktır . 2 yönlü el sıkışmasında yarım bağlantı senaryosu:
1) Müşteri --- SYN -> Sunucu
2) Müşteri fikrini değiştirdi ve artık bağlanmak istemiyor
3) Müşteri <-X-ACK-- Sunucu // ACK kaybedildi
Sunucu, resent SYN'yi görmüyor, bu nedenle müşterisinin ACK'sını aldığını ve bağlantının kurulduğunu düşünüyor. Sonuç olarak, Sunucunun asla kapatılamayacak bir bağlantısı var.