왜 3 방향 핸드 셰이크가 필요합니까? 왜 양방향이 아닌가?

TCP 3 방향 핸드 셰이크는 다음과 같이 작동합니다.

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

왜 이러지 않습니까?

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

악수를 실제로하고있는 일로 나누십시오.

TCP에서 두 당사자는 시퀀스 번호를 사용하여 전송 한 내용을 추적합니다. 실제로 전송 된 모든 바이트 수를 실행합니다. 수신 측은 상대방의 시퀀스 번호를 사용하여 수신 한 것을 인식 할 수 있습니다.

그러나 시퀀스 번호는 0에서 시작하지 않습니다. 임의로 선택된 값인 ISN (Initial Sequence Number)에서 시작합니다. TCP는 양방향 통신이므로 두 당사자 모두 "발언"할 수 있으므로 둘 다 시작 시퀀스 번호로 ISN을 임의로 생성해야합니다. 즉, 양 당사자는 상대방에게 자신의 시작 ISN을 통지해야합니다.

따라서 Alice와 Bob 사이의 TCP 대화를 시작하기 위해 다음과 같은 일련의 이벤트가 발생합니다.

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]

네 가지 이벤트가 발생합니다.

1. Alice는 ISN을 선택하고 Bob 과 동기화 합니다.
2. 밥 은 ISN을 알고 있다.
3. Bob은 ISN을 선택하고 Alice 와 동기화 합니다.
4. Alice 는 ISN을 인정 합니다.

그러나 실제로 두 개의 중간 이벤트 (# 2 및 # 3)는 동일한 패킷에서 발생합니다. 각 TCP 헤더 내 에서 패킷을 만들 SYN거나 ACK단순히 이진 플래그를 켜거나 끄는 이유는 동일한 패킷에서 두 플래그를 모두 사용할 수있게하는 것입니다. 따라서 3 방향 핸드 셰이크는 다음과 같습니다.

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

"SYN"과 "ACK"의 두 인스턴스가 각각 양방향으로 나타납니다.

질문으로 돌아가려면 양방향 핸드 셰이크 만 사용하는 것이 어떻습니까? 짧은 대답은 양방향 핸드 셰이크가 한 당사자 만 ISN을 설정하고 다른 당사자는이를 승인 할 수 있기 때문입니다. 즉, 한 당사자 만 데이터를 보낼 수 있습니다.

그러나 TCP는 양방향 통신 프로토콜이므로 데이터를 안정적으로 전송할 수 있어야합니다. 양 당사자는 ISN을 설정해야하며 양 당사자는 상대방의 ISN을 인정해야합니다.

실제로, 당신이 가진 것은 양방향 핸드 셰이크에 대한 당신의 설명이지만 , 각 방향으로 입니다. 따라서 네 가지 이벤트가 발생합니다. 그리고 다시, 중간 두 플래그는 동일한 패킷에서 발생합니다. 이러한 3 개의 패킷은 완전한 TCP 연결 시작 프로세스에 관여합니다.

양 당사자가해야하기 때문에 세 방향 핸드 셰이크가 필요 SYN chronize에게 자신의 전송시 사용되는 자신의 세그먼트 시퀀스 번호를. 이를 위해, 이들 각각은 (결과적으로) 임의의 값으로 설정하는 시퀀스 번호와 SYN 세그먼트 전송 N 다음되고, ACK 설정된 시퀀스 번호와 함께 ACK 세그먼트를 통해 상대방 nowledged N + 1 .

연결이 작동하려면 각 쪽에서 다른쪽으로 패킷을 보낼 수 있는지 확인해야합니다. 당신이 다른쪽에 패킷을 가지고 있는지 확인하는 유일한 방법은 당신이 보낸 패킷이 통과하지 않는 한, 정의에 의해 전송되지 않은 패킷을 가져 오는 것입니다 . TCP는 본질적으로이를 위해 SYN (이 패킷이 통과했음을 증명하기 위해)과 ACK (SYN이 통과 한 후에 만 ​​전송되어 SYN이 통과했음을 증명하는)의 두 가지 메시지를 사용합니다. 실제로 세 번째 종류의 메시지가 있지만 잠시 후에 그 사실을 알게 될 것입니다.

연결이 시작되기 전에 어느 쪽도 상대방에 대해 아무것도 알지 못합니다. 클라이언트는 SYN 패킷을 서버로 보내 메시지가 통과 할 수 있다는 증거를 요청합니다 . 그것은 아무에게도 말하지 않지만 악수의 첫 단계입니다.

SYN이 통과하면 서버는 클라이언트가 패킷을 전송할 수 있다는 것을 알게됩니다. 그러나 이것이 서버가 패킷을 다시 보낼 수 있다는 것을 증명하지는 않습니다. 클라이언트는 많은 이유로 SYN을 보낼 수 있습니다 . 따라서 서버는 ACK (SYN이 통과했음을 증명하기 위해)와 SYN (자체 ACK를 요청하기 위해)의 두 가지 메시지를 클라이언트로 다시 보내야합니다. TCP는 네트워크 트래픽을 줄이려면이 두 메시지를 하나의 SYN-ACK 메시지로 결합합니다. 이것이 악수의 두 번째 단계입니다.

SYN-ACK는 ACK이므로 클라이언트는 이제 서버로 패킷을 보낼 수 있는지 확인합니다. 또한 SYN-ACK는 SYN이기 때문에 서버는이 메시지가 통과했다는 증거를 원한다는 것도 알고 있습니다. 따라서 ACK를 다시 보냅니다. 이번에는 일반 ACK입니다. 더 이상 패킷이 통과 할 수 있다는 증거가 필요하지 않기 때문입니다. 이것이 핸드 셰이크의 마지막 단계입니다. 이제 클라이언트는 패킷이 양방향으로 이동할 수 있다는 것을 알고 있으며 서버는 ACK가 통과한다는 것을 알기 때문에이를 파악 하려고 합니다.

해당 ACK가 통과되면 서버는 클라이언트에게 패킷을 보낼 수 있음을 알게됩니다 . 또한 클라이언트가이 사실을 알고 있으므로 데이터 전송을 바로 시작할 수 있습니다. 악수가 완료되었습니다. 좋은 채널이 있습니다.

엄밀히 말하면, 우리는 좋은 채널을 가지고 있다고 확신 할 수 없습니다 . 이러한 일련의 패킷이 통과 했다고해서 다른 사람들이 엄격하게 보장 하지는 않습니다 . 우리는 무한한 수의 SYN과 ACK를 보내지 않으면 다른 어떤 것도 할 수 없다는 것을 증명할 수 없으므로 실제로 실용적인 옵션은 아닙니다. 그러나 실제로는 세 단계가 대부분의 목적에 충분한 것으로 밝혀졌습니다 .

실제로 3 방향 핸드 셰이크가 TCP 연결을 설정하는 유일한 수단은 아닙니다. 동시 SYN 교환도 허용됩니다. http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm

일종의 이중 양방향 핸드 셰이크로 볼 수 있습니다.

TCP 연결은 양방향입니다. 이것이 의미하는 것은 실제로 단방향 연결 쌍이라는 것입니다. 초기자는 SYN을 보내고 응답자는 ACK를 보냅니다. 하나의 단일 연결이 시작됩니다. "응답자"는 SYN을 보내고, 개시자는 ACK를 보냅니다. 다른 단일 연결이 시작됩니다. 두 개의 단일 연결이 하나의 이중 TCP 세션을 형성합니다. 논리적으로 네 단계가 있습니다. 그러나 SYN 및 ACK 플래그는 TCP 헤더의 "필드"가 다르기 때문에 동시에 설정할 수 있습니다. 두 번째와 세 번째 단계 (4 개 중 2 단계)가 결합되어 기술적으로 3 개의 패킷 교환이 있습니다. 각 심플 렉스 (하프) 연결은 제안한대로 양방향 교환을 사용합니다.

서버와 클라이언트가 연결을 만들려면 다음 네 가지를 확인해야합니다.

1. 서버가 클라이언트로부터 패킷을 수신 할 수 있는지 확인해야합니다.

2. 클라이언트는 서버에서 패킷을 수신 할 수 있는지 확인해야합니다.

3. 클라이언트가 확인해야 할 사항 : 서버가 클라이언트로부터 패킷을 수신 할 수 있음

4. 서버가 확인해야 할 사항 : 클라이언트가 서버에서 패킷을 수신 할 수 있음

이후 Client ------SYN-----> Server규칙 1이 확인됩니다.

이후에 Client <---ACK/SYN---- Server, 규칙 2 및 3이 확인된다.

따라서 규칙 4를 확인하려면 세 번째 패킷이 필요합니다.

전혀 필요하지 않습니다. 단문 메시지는 서버에 시작 + 메시지를 포함하는 하나의 패킷과이를 확인하는 하나의 패킷 만 필요로하는 것이 분명합니다.

이전 답변은 무작위 시퀀스 번호 등의 필요성에 대해 논의하지 않고 시스템을 설명했습니다. 원래 질문은 TCP 자체 디자인에 관한 것이 었습니다. 분명히 TCP 프로토콜을 사용하는 경우 프로토콜이므로 세 가지 메시지가 필요합니다. 그러나 왜 TCP가 처음에 그렇게 설계 되었습니까?

원래 아이디어는 클라이언트와 서버 사이에 차이가 없다는 것이 었습니다. 둘 다 상대방의 포트를 양방향으로 알고 있으며 대화를 시작할 수 있습니다. 그리고 그것은 Syns 등이 필요했습니다.

그러나 이것이 오늘날 그것이 어떻게 사용되는지는 아닙니다. 서버는 잘 알려진 포트에서 수신 대기하며 "수용"합니다. 클라이언트 포트 번호는 일시적입니다. "수락"대기중인 서버 가 일반 운영 체제에서 동일한 클라이언트 포트 번호 로 다른 요청을 보낼 수 있다고 생각조차하지 않습니다 .

(이것은 연결의 양방향 시작에 관한 것이며 오늘은 결코 이루어지지 않습니다. 이는 일단 연결되면 양방향 메시지를 연결로 보내는 것과는 다릅니다.)

TCP 비 효율성을 해결하기 위해 여러 요청에 동일한 연결을 재사용 할 수있는 HTTP 1.1과 같은 프로토콜을 사용하므로 처음에는 필요하지 않은 TCP 핸드 셰이크를 피할 수 있습니다.

그러나 Http 1.1은 비교적 새롭습니다. 그리고 SSL / TLS는 PKI 알고리즘 비용으로 인해 처음부터 세션을 재사용 할 수있는 방법이 필요했습니다. 따라서 프로토콜에는 TCP 위에서 실행되는 Http 1.1 위에서 실행되는 자체 세션 재사용 메커니즘이 포함됩니다.

소프트웨어가 그런 식입니다. 결합 될 때 수용 가능한 결과를 생성하는 kludges에 퍼지.

Eddie의 답변을 읽은 후에 (올바른 것으로 받아 들여짐), 왜 첫 번째 호스트가 ISN을 임의의 숫자로 할당 할 수없고 두 번째는 그것을 받아 들일 수 있는지에 대한 의문이 여전히 남아 있습니다. 3 방향 핸드 셰이크를 사용하는 실제 이유는 반 연결 을 피하기위한 것 입니다. 양방향 핸드 셰이크의 절반 연결 시나리오 :
1) 클라이언트 --- SYN- > 서버
2) 클라이언트가 마음을 바꾸고 더 이상 연결하고 싶지 않음
3) 클라이언트 <-X-ACK-- 서버 // ACK가 손실 됨
서버는 재전송 된 SYN을 보지 못하므로 클라이언트가 ACK를 받고 연결이 설정되었다고 생각합니다. 결과적으로 서버는 절대 닫히지 않는 연결을 갖습니다.