http://www.cnblogs.com/cy568searchx/p/3711670.html
TCP (전송 제어 프로토콜) 전송 제어 프로토콜
세 방향 핸드 셰이크
TCP는 호스트가 전송 제어 프로토콜 계층을 호스팅하는 신뢰할 수있는 연결 서비스를 제공하는 것입니다, 연결 확인을 설정하는 세 방향 핸드 셰이크 :
즉, TCP 플래그 비트 코드 여섯 종류가있다 깃발 : SYN (동기 연결 설정) ACK (승인 확인) PSH (푸시 전송) FIN (마무리 말) RST (재설정 재설정) URG (긴급 비상)
일련 번호 (일련 번호) 번호 (확인 번호를) 인정
제 악수 : 호스트 B는 SYN = 1, 접속을 확립하기위한 요구를 알고 의해 호스트 A는 서버 비트 코드 SYN = 1, 임의로 생성 된 서열 번호 = 1234567 개 패킷 데이터를 전송한다;
둘째 악수 : SYN 접속 응답 메시지에 대한 요청을 수신 한 후 호스트 B, 전송할 ACK 번호 A = (호스트 서열 + 1) = 1, 1 = ACK, 임의로 생성 된 패킷 SEQ = 7,654,321
셋째 악수 : 호스트 A는 상기 ACK 번호 확인, 즉, 제 1 전송 서열 번호 + 1이며, 상기 ACK 비트 코드가 올 경우, 호스트 A는 ACK 번호 = (호스트 B를 송신하고, 1, 올바른 수신 서열 + 1), ACK = 1, 호스트 B는 성공적으로 연결되는 응답 서열 값 1 = ACK 수신한다.
핸드 완료 삼방, 호스트 (A)와 호스트 B는 데이터를 전송하기 시작한다.
TCP / IP 프로토콜에서 TCP 프로토콜이 연결을 설정하는 신뢰할 수있는 연결 서비스, 세 방향 핸드 셰이크를 제공합니다.
제 악수 : 연결이 확립되고, 클라이언트는 서버의 SYN 패킷 (SYN = J)를 전송하고, 확인 서버 기다리는 상태 SYN_SEND 들어간다
제 악수 : 서버는 SYN 패킷을 수신하고, 고객 SYN을 (확인해야 ACK = J + 1) 자체는 SYN 패킷을 전송하는 동안 (SYN = k)는, 즉, SYN + ACK 패킷, 서버가 상태 SYN_RECV 입사 셋째 악수 : 클라이언트가 서버로 SYN + ACK 패킷을 수신하고, 서버는 확인 패킷을 전송 ACK (ACK = K + 1) , 상기 설정된 상태로이 패킷이 전송되고, 클라이언트와 서버는 세 방향 핸드 셰이크를 수행. 전체 세 방향 핸드 셰이크, 클라이언트와 서버가 데이터를 전송하기 시작한다.
예 :
IP 192.168.1.116.3337> 192.168.1.123.7788 : S 3626544836 : 3626544836
IP 192.168.1.123.7788> 192.168.1.116.3337 : S 1739326486 : 1739326486 ACK 3626544837
IP 192.168.1.116.3337> 192.168.1.123.7788 : ACK 1,739,326,487 1, ACK
제 악수 : 192.168.1.116 송신 비트 코드 SYN = 1, 무작위로 생성 된 데이터 패킷 서열 번호 = 3,626,544,836 192.168.1.123,192.168.1.123 SYN = 1 192.168.1.116 연결을 설정 항 알고;
둘째 악수 : 192.168.1.123에서 연결 응답 메시지에 대한 요청을 수신 한 후 ACK를 보낼 수 = 3,626,544,837 192.168.1.116, SYN = 1, 1 = ACK, 임의로 생성 된 서열 패킷 = 1,739,326,486;
셋째 악수 : 192.168.1.116가 검사 ACK 번호를받은 후, 올바른 즉, 처음 서열 번호 + 1, 및 전송에 대한 ACK 비트 코드 192.168.1.116 후 ACK 번호 = 1,739,326,487를 보낼 올바른 경우, 1, 연결이 성공적으로 설정 ACK = 1 = ACK 확인 1,192.168.1.123 서열 SEQ = + 1을 수신 한 후.
그림 :
세 방향 핸드 쉐이크 (..도 1,도 2)
(도. 1)
(도. 2)
제 악수 플래그 (도 3)
우리 요청합니다 (SYN)를 수행, 즉, 단 하나의 플래그 동기 비트가 있음을 볼 수있다
(3)
제 악수 플래그 (도 4)
우리 보시 확인 플래그 비트 동기화 비트가 있는데, 즉, 대답합니다 (SYN + ACK)을 수행한다
(도 4)
플래그 (도 5) 제 악수
, 즉, 우리가 조금 인정 하나의 플래그가 있음을 알 수 있습니다, 재확인 (ACK) 않는다
(그림 5)
완전한 세 방향 핸드 셰이크가 요청 --- --- 응답 재확인
네 브레이크 업 :
TCP 연결은 전이중 (full-duplex)이기 때문에, 각각의 방향은 개별적으로 종료해야합니다. 원리는 하나의 작업이 완료되면 데이터 전송이 연결 방향을 종료하는 FIN을 보낼 수 있다는 것입니다. FIN을 만 데이터가이 방향으로 흐르는하지 않음을 의미 수신, TCP 연결은 여전히 FIN을받은 후 데이터를 보낼 수 있습니다. 다른 수동 확대를 수행하는 동안 첫째는 활성 확대를 수행하도록 한 것이다.
(1) 클라이언트는 서버 B를 클라이언트 A를 폐쇄하는 FIN을 전송하는 것은 데이터 (세그먼트 4)를 송신한다.
(2) 서버 B가 FIN을 수신하면 ACK가, 수신 확인 응답 시퀀스 번호에 1을 더한 (부분 5)를 다시 송신한다. 그리고 FIN과 같은 SYN 숫자를 취할 것입니다.
(3) 클라이언트가 FIN A (세그먼트 6)를 전송하고, 서버 B가 클라이언트 A에 접속되어 닫힌다.
(4) 클라이언트 1 (세그먼트 7)에 의해 수신 된 순서 번호를 증가시켜 ACK 메시지가 ACK를 회신한다.
자세한 상태 :
CLOSED : 거기에 아무것도 정말없고, 초기 상태 것이다.
LISTEN :이 상태를 이해하는 것도 매우 쉽습니다 청취 상태에서 소켓 서버를 나타냅니다, 당신은 연결을 받아 들일 수 있습니다.
SYN_RCVD :이 상태는 TCP 연결 프로세스를 설정할 때이 상태가 서버 측 세션 SOCKET 세 방향 핸드 셰이크의 중간 상태, 정상적인 상황에서, SYN 패킷을 수신 의미, 매우 짧은, 기본적으로는 NETSTAT로 볼 어렵다 이 상태는 의도적으로 클라이언트 테스트 프로그램, 세 번 마지막 ACK 패킷이 전송되지 않습니다 의도적으로 TCP 핸드 쉐이크를 작성하지 않는 한. 클라이언트는 ACK 패킷을 수신 할 때 따라서,이 상태는, 그 확립 된 상태로된다.
SYN_SENT : 클라이언트 SOCKET 연결 접속을 실행 상태로 돌아 가기 SYN_RCVD 방법 에코는, 그것이 먼저 SYN 패킷을 전송하고, 따라서 그 때 SYN_SENT 상태로 입력되며, 처음 두 메시지 핸드 셰이크 3 배 서비스 측으로 전송 대기. 클라이언트가 SYN 패킷을 전송되었음을 SYN_SENT 상태입니다.
설립 :이 연결이 설정되어 있는지 이해하기 쉽다.
FIN_WAIT_1 : 상태는 제대로 FIN_WAIT_1의 진정한 의미를 설명하고 실제로 FIN_WAIT_2 상태는 다른 측면을 기다리고 FIN 메시지가 표시됩니다. 이 두 상태 사이의 차이는 다음과 같습니다, 소켓이 확립 된 상태에서, 그것은 연결을 닫습니다 주도권을 쥐고하고자 할 때 FIN_WAIT_1 상태가 실제로 서로에 FIN 패킷을 전송, 그 다음이 FIN_WAIT_1 상태로 소켓입니다. 상대방이 패킷을 ACK로 응답 할 때, 그것은 실제 정상적인 상황에서, 상대방이 즉시 응답해야 어떤 상황에 상관없이 그렇게 FIN_WAIT_1 상태가 일반적으로 보는 것은 더 어렵습니다, 패킷을 ACK,하고, 물론, FIN_WAIT_2 상태가 자주 NETSTAT 거기 볼 수 있습니다 FIN_WAIT_2 상태입니다.
FIN_WAIT_2는 : 이미 사실 소켓 FIN_WAIT_2 상태로,이 상태에서 자세히 설명한 바와 같이, 나타내는 반 연결 한 당사자가 나중에 다시 당신에게 전송 나는 약간의 데이터를 수행 밀접한 관계를 필요로하지만, 또한 서로에게 것을, 연결을 닫습니다.
TIME_WAIT는 : 2MSL 사용할 수 CLOSED 후 상태로 복귀하는 것, 서로의 FIN 패킷의 수신을 인정하고, ACK 패킷을 전송한다. 다른 하나는 FIN 플래그와 ACK 플래그 패킷을 수신하는 동안 다음 FIN_WAIT_1 상태 경우, 당신은 FIN_WAIT_2 상태를 거치지 않고 TIME_WAIT 상태로 바로 이동할 수 있습니다.
CLOSING :이 상태는 다소 특별하다, 현실은 희귀해야한다, 그것은 예외의 비교적 드문 상태입니다. 당신이 FIN 메시지를 보낼 때 정상적인 상황에서는, 논리적으로, 먼저 받아야한다 (또는 동시에 수신) 서로의 ACK 패킷, FIN 메시지 수신을 중지합니다. 그러나 상태를 닫으면 당신이 FIN 패킷을 보낸 후 의미하며, 더 ACK 패킷을 수신,하지만 그들은 또한 서로의 FIN 패킷을 받았다. 이것은 어떤 상황에서 다음이 일어날 수 있습니까? 사실, 생각, 결론을 어렵지 않다 : 즉, 거의 동시에 양측이 소켓을 닫으면, 다음의 경우 양측은 또한 폐문 상태를 나타납니다 또한, FIN 메시지를 보낼 등장 양측이 폐쇄 소켓 연결되고있다 고 말했다 .
CLOSE_WAIT :이 사실의 의미가 기다리고 닫힌 상태입니다. 어떻게 이해 하는가? 상대방이 소켓이 자신에게 FIN 메시지를 보낼 닫을 때, 시스템은 의심의 여지가 상대방에 ACK 패킷으로 응답하지 않습니다, 다음 상태를 CLOSE_WAIT로 진행한다. 지금은, 사실, 당신이 정말 고려할 필요가하면, 상대방에게 보낼 수없는 경우, 당신은 또한이 연결을 종료하고, 서로 FIN 메시지를 소켓을 닫습니다 보낼 수 있습니다 더 많은 데이터가보고 여부 것입니다. 그래서 당신은 CLOSE_WAIT 상태로,이 일을해야 당신이 연결을 닫을 때까지 기다려야하는 것입니다.
LAST_ACK :이 상태는 마지막 ACK 패킷의 다른 측면을 기다리고, FIN 패킷을 전송 한 후 파티 아래로 수동 차단, 더 잘 이해하기가 비교적 쉽다. 상기 ACK 패킷을 수신하면, 즉 닫힌 상태가 가능 들어갈 수있다.
요약 :
1. 연결 동의를 설정하고 그것을 연결 핸드 셰이크입니다 닫 세 방향 핸드 셰이크는 왜?
소켓에도 요청 SYN 패킷의 수신 후에 구조의 단부에 주 서비스 청취하기 때문이고, 그 패킷에 배치 SYN 및 (동기화 역할로부터 ACK 응답 및 SYN) ACK을 보낼 수있다. 그것은 서로의 FIN 메시지 알림을 수신 할 때이 연결을 닫습니다, 그것은 단지 사람이 있다는 데이터가 사용자에게 전송되지 나타내며, 그러나 반드시 모든 당신의 모든 데이터가 상대방에게 전송 한 그렇게 할 수 있습니다 반드시 즉시 폐쇄 소켓, 대부분의 경우가 여기에 ACK 패킷과 FIN 패킷이 별도로 전송됩니다, 그래서 당신은 또한 후 서로 어떤 데이터를 전송해야 할 수도 있음을, 다음, 당신은 우리가 지금 연결을 닫을 수 있습니다 동의 란에 서로 FIN 메시지를 보냅니다.
2. 왜 2MSL 후 TIME_WAIT 상태는 CLOSED 상태로 돌아 기다릴 필요가?
이는 양측이 연결을 종료, 4 개 핸드 쉐이크 패킷도 조정 및 전송에 동의하지만, 가정 (상태로 상태를 수립 SYN_SEND에서 그 같은) CLOSED 상태로 돌아갈 수 있기 때문이다, 그러나 우리는 상상하기 때문에 네트워크는 그래서, 당신은 당신이 마지막 ACK 패킷 확실히, 상대방이 ACK 패킷 때문에 초과 근무 수당을받지 못할 수 있습니다 다음 소켓의 LAST_ACK 상태에있을 것입니다 상대방 수신합니다 전송 보장 할 수 없습니다, 신뢰할 수 없습니다, 패킷의 FIN을 재전송 TIME_WAIT 상태의 역할이 손실 될 수도있다 ACK 패킷을 재전송하기 위해 사용된다.
-------------------
TCP 협정 말하기, 모든 작은 사람들이 조금 될 수있는 각 상태 (SYNC_SENT, CLOSE_WAIT ...... 등)을 유창하게 읽을 네 세 방향 핸드 셰이크 및 분리를 구사하고 Niubi 할 수 있습니다 , 철회
그리고 그는 소켓 프로그래밍, 네트워크 프로그래밍은 기본적으로 여러 사람이 표준 API에 익숙 할 것이라고 썼습니다 말했다 : 소켓, 연결, 듣고, 받아 들인다. . . . . . 잠깐만 요
하지만 아주 소수의 사람들이 국가와 TCP 소켓 프로그래밍 API 사이의 관계를 이해 내기. 믿을 수 있습니까? 당신이 그것을 알고 있다면 다음과 같은 질문에 살펴 보자 :
1) 클라이언트가 서버 종료 후 또는 결합 또는 듣고 전화 후, 서버 측에 연결할 수있을 때 후 동의?
2) 어떤 상황에서 FIN_WAIT_2 상태가있을 것입니다
.....................
이번 주, 종교 재판관은 정신과 사실에서 진실을 추구하는 정신은, 내가 파이썬 스크립트를 읽은 후 당신이 휘는 것, 이러한 상황을 테스트하기 위해 몇 가지 스크립트를 작성 사용 결국 물었다, 다시 새로운 차원의 TCP 소켓 프로그래밍의 프로토콜의 이해.
참고 : 다음 테스트는 리눅스에서 파이썬 (2.7) 테스트 스크립트 (2.6.18) 플랫폼이며, 다른 플랫폼은 테스트하지 않은, 스스로를 테스트 할 수 있습니다 관심이 있습니다.
[연결 프로세스 및 검증 테스트]
사례 1 : 클라이언트 통화 연결, 서버가 단지들을 호출하지 않는 소켓 + 바인딩 전화
tcpdump를 패킷 캡처 다음과 같습니다 :
미묘한 결과가 나타났다 : 서버 단말 RST 패킷이 직접 회신
클라이언트 또는 서버를 보거나 SS 위해 netstat 명령을 사용하여 이번에는 연결을 발견하고있다
사례 2 : 클라이언트 전화 연결, 서버라고 소켓 + 바인딩 + 듣기
tcpdump를 패킷 캡처 다음과 같습니다 :
세 방향 핸드 셰이크가 완료 : 미묘한 결과는 것을 보여 주었다
SS를 사용하여 도구를 보려면 클라이언트와 서버가 표시됩니다 맛 음료
- [liyh @ localhost를 ~] $의 SS는 -n -t | 그렙 50000
- 맛 음료 0 0 10.1.73.45:55354 10.1.73.76:50000
사례 3 : 클라이언트 호출을 수락 + RECV + 전송, 전송 서버라고 소켓 + 바인딩 + +들을 연결 +
tcpdump를 패킷 캡처 다음과 같습니다 :
세 방향 핸드 셰이크가 완료되고, 양측 전송하고 데이터를 수신 할 수 있습니다 미묘한 결과는 것을 보여 주었다
SS를 사용하여 도구를 보려면 클라이언트와 서버가 표시됩니다 맛 음료
- [liyh @ localhost를 ~] $의 SS는 -n -t | 그렙 50000
- 맛 음료 0 0 10.1.73.45:41363 10.1.73.76:50000
[요약] 접속 처리
1) 서버 종료 후 듣는 경우에만 볼 수 있습니다, 클라이언트 측 호출이 성공에 연결, 그렇지 않으면 응답이 RST를 반환 연결을 거부합니다
2）只有当accept后，client和server才能调用recv和send等io操作
3）socket API调用错误不会导致client出现SYN_SENT状态，那么只能是网络设备丢包（路由器、防火墙）才会导致SYNC_SENT状态
【断连过程测试和总结】
第1种情况：client调用close，但server没有调用close
tcpdump抓包如下：
抓包结果显示：client发送了fin包，server端应答了ack包
使用ss工具去查看，client显示FIN_WAIT_2状态：
[html] view plain copy
- [liyh@localhost ~]$ ss -t -n | grep "10.1.73.76:50000"
- FIN-WAIT-2 0 0 10.1.73.45:47630 10.1.73.76:50000
server显示CLOSE-WAIT状态
[html] view plain copy
- [jws@jae_test ~]$ ss -t -n | grep 50000
- CLOSE-WAIT 1 0 10.1.73.76:50000 10.1.73.45:47630
而且有一个值得注意的现象是：client的连接过一段时间就没有了，而server的连接一直处于CLOSE_WAIT状态
原因在于Linux系统内核中有一个参数可以控制FIN_WAIT_2的时间：tcp_fin_timeout
第2种情况：client调用close，server调用close
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
使用ss工具去查看，client显示TIME-WAIT状态
[html] view plain copy
- [liyh@localhost ipv4]$ ss -a -n | grep 50000
- TIME-WAIT 0 0 10.1.73.45:39751 10.1.73.76:50000
server端使用ss工具去看已经看不到连接了
第3种情况：server端被kill了
tcpdump抓包如下：
抓包结果显示：熟悉的四次断连来啦
咦，怎么会和正常的server close一样呢？答案就在于操作系统的实现：
close函数其实本身不会导致tcp协议栈立刻发送fin包，而只是将socket文件的引用计数减1，当socket文件的引用计数变为0的时候，操作系统会自动关闭tcp连接，此时才会发送fin包。
这也是多进程编程需要特别注意的一点，父进程中一定要将socket文件描述符close，否则运行一段时间后就可能会出现操作系统提示too many open files
第4种情况：client端调用shutdown操作
shutdown操作有三种关闭方式：SHUT_RD、SHUT_WR、SHUT_RDWR，分别测试后发现有趣的现象。
1）如果是SHUT_RD，则tcpdump抓包发现没有发送任何包；
2）如果是SHUT_WR或者SHUT_RDWR，则client会发送FIN包给server，
若server收到后执行close操作，则server发送FIN给client，最终连接被关闭。
SHUT_WR或者SHUT_RDWR抓包显示如下：
使用ss命令查看，client显示如下：
[html] view plain copy
- [liyh@localhost ~]$ ss -a | grep 50000
- TIME-WAIT 0 0 10.1.73.45:45641 10.1.73.76:50000
server显示连接已经被关闭了。
HTTP : //www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html 자세한 설명 종료는 참조 할 수 있습니다
프로세스 SHUT_RD를 요약 :
새로운 데이터가 직접 도착하면 1) 클라이언트 단말기는 더 이상 데이터를 수신하지 않습니다 폐기 (거부)
2) 임의의 TCP 패킷을 전송하지 않고, 서버 쪽에서는 머리카락으로 만들어진) 서버 측이 데이터를 계속 전송할 수 있고,이 상태를 알고 있지만 인해 1 않는다
치료의 SHUT_WR 또는 SHUT_RDWR를 요약 :
1, 기록 동작이 호출 될 수없는) 데이터 전송을 중지 (기입 호출하지만 된 미 송신 데이터 버퍼를 폐기하지 하부 전송 프로토콜 스택의 TCP)
2) 정지 요청 메시지, 데이터를 확인되지 않은 재전송 된 데이터가 더 이상 보내신 전송되지
[단선 처리 개요]
카운트가 0으로 감소 할 때 1) 가까이 소켓 파일 단순히 참조 카운트를 감소 운영체제는 절단 동작을 수행하는 TCP
2) 가까운 서버, 클라이언트 측 접속 상태를 확대하지 않고 발생할 클라이언트 측 FIN_WAIT_2 종료 후, 접속 상태의 서버 단부가된다 CLOSE_WAIT
통상 프로그램 확실히 그렇게 간주되지 (C ++ / JAVA 등) 가까이로 연결되지 않는 점프 예외 처리에서 일반적으로, 또는 전체 시스템의 이상 원인에 근접하지 (예컨대 JVM 메모리는 메모리 오류에서 나타남)
처리 로직의 3) 종료는 잘못하기 쉬운, 더 복잡한, 비 특수 상황이 엉망을하지 않는 것입니다
4) 프로세스는 운영 시스템이 자동으로 소켓을 회복 종료, TCP는 과정 시작 작업을 종료