TCP\IP三次握手连接，四次握手断开分析

TCP(Transmission Control Protocol)　传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(发送序列) Acknowledge number(确认序列)

第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机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)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据.

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）

四次握手断开：

由于 TCP 连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN 来终止这个方向的发送通道。收到一个 FIN 只意味着这一方向上没有数据流动，一个 TCP 连接在收到一个 FIN 后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。  
（ 1 ）客户端 A 发送一个 FIN ，用来关闭客户 A 到服务器 B 的数据传送（报文段 4 ）。  
（ 2 ）服务器 B 收到这个 FIN ，它发回一个 ACK ，确认序号为收到的序号加 1 （报文段 5 ）。和 SYN 一样，一个FIN 将占用一个序号。  
（ 3 ）服务器 B 关闭与客户端 A 的连接，发送一个 FIN 给客户端 A （报文段 6 ）。  
（ 4 ）客户端 A 发回 ACK 报文确认，并将确认序号设置为收到序号加 1 （报文段 7 ）。  

 

 

实例:
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 1739326487,ack 1
第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。

http实例：
pc浏览服务器网页此过程不包括域名查询，只描述TCP与http数据流的变化。
一、pc与http服务器进行三次握手来建立连接。
1.pc：seq=0 ack=0 syn=1 ack=0 发送给服务器建立同步请求。
2.server： seq=0 ack=1 syn=1 ack=1 发送给客户端建立同步响应.
3.pc:seq=1 ack=1 syn=0 ack=1 发送给服务器,三次握手完成建立同步信息成功.
4.pc产生http数据消息,向服务器发送get请求.
5.服务器收到请求并发送TCP确认,然后发送http数据信息给客户端的浏览器.
6.客户端收到服务器的http信息,然后发送TCP确认信息给服务器.
7.客户端发送FIN+ACK给服务器,要求结束数据传输.
8.服务器发送TCP确认消息用于确认pc的TCP的FIN消息
9.服务器向客户端发送FIN+ACK消息用于结束TCP会话.
10.客户端发送确认信息给服务器,整个会话结束.

HTTP连接
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常 的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
问题:
1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？  
这是因为服务端的 LISTEN 状态下的 SOCKET 当收 到 SYN 报文的建立连接请求后，它可以把 ACK 和 SYN （ ACK 起应答作用，而 SYN 起同步作用）放在一个报文里来发送。但关闭连接时， 当收到对方的 FIN 报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭 SOCKET, 也即你可能还需要发送一些数据给对方之后，再发送 FIN 报文给对方来表示你同意现在可以关闭连接了，所以它这里的 ACK 报文 和 FIN报文多数情况下都是分开发送的。  
2．为什么 TIME_WAIT 状态还需要等 2MSL 后才能返回到 CLOSED 状态？  
这是因为虽然双方都同意关闭连接了，而且握手的 4 个报文也都协调和发送完毕，按理可以直接回到 CLOSED 状态（就好比从 SYN_SEND 状态 到 ESTABLISH 状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的 ACK 报文会一定被对方收到，因此对方处 于 LAST_ACK 状态下的 SOCKET 可能会因为超时未收到 ACK 报文，而重发 FIN 报文，所以这个 TIME_WAIT 状态的作用 就是用来重发可能丢失的 ACK 报文

总结：
三次握手，三种状态（SYN_SEND\SYN_RECV\ESTABLISHED）；两种包(请求包\应答包)，两样东西（标志位码\序列号码）
四次握手，两次分开
心跳监测（client-<保持>-server-<在线>-client）

参考博客：

http://www.cnblogs.com/rosesmall/archive/2012/04/09/2439726.html

http://www.cnblogs.com/persist/p/3166225.html

TCP协议连接建立时3次握手的过程。

简述TCP协议连接建立时3次握手的过程。 根据TCP头部，说明下列3个包在连接建立过程中的次序. 0020        00 50 83 aa 46 49 3e dd 33 96 37 a3 a0 12  ...P..FI>.3.7... 0030   16 a0 c4 c0 00 00 02 04 05 b4 04 02 08 0a d7 9b  ................ 0040   62 b7 00 56 4a 2a 01 03 03 02                    b..VJ*....   （1） 0020        83 aa 00 50 33 96 37 a2 00 00 00 00 a0 02  .....P3.7....... 0030   16 d0 84 1d 00 00 02 04 05 b4 04 02 08 0a 00 56  ...............V 0040   4a 2a 00 00 00 00 01 03 03 00                    J*........    （2） 0020        83 aa 00 50 33 96 37 a3 46 49 3e de 80 10  .....P3.7.FI>... 0030   16 d0 f3 4b 00 00 01 01 08 0a 00 56 4a 36 d7 9b  ...K.......VJ6.. 0040   62 b7                                            b.    （3）   解： 在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。   1）是第二次握手，flags位上为12，二进制是0001 0010，即表示有syn和ack. 2）是第一次握手，flags位上为02，二进制是0000 0010，即表示有syn没有ack。 3）是第三次握手，flags位上为10，二进制是0001 0000，即表示有ack没有syn。   该连接访问的是80端口，是为HTTP（HyperText Transport Protocol，超文本传输协议）开放的， 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；  第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；  第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。  完成三次握手，客户端与服务器开始传送数据。 tcp-断开连接:   主要部分，四次握手： 断开连接其实从我的角度看不区分客户端和服务器端，任何一方都可以调用close(or closesocket)之类 的函数开始主动终止一个连接。这里先暂时说正常情况。当调用close函数断开一个连接时，主动断开的 一方发送FIN(finish报文给对方。有了之前的经验，我想你应该明白我说的FIN报文时什么东西。也就是 一个设置了FIN标志位的报文段。FIN报文也可能附加用户数据，如果这一方还有数据要发送时，将数据附 加到这个FIN报文时完全正常的。之后你会看到，这种附加报文还会有很多，例如ACK报文。我们所要把握 的原则是，TCP肯定会力所能及地达到最大效率，所以你能够想到的优化方法，我想TCP都会想到。 当被动关闭的一方收到FIN报文时，它会发送ACK确认报文(对于ACK这个东西你应该很熟悉了)。这里有个 东西要注意，因为TCP是双工的，也就是说，你可以想象一对TCP连接上有两条数据通路。当发送FIN报文 时，意思是说，发送FIN的一端就不能发送数据，也就是关闭了其中一条数据通路。被动关闭的一端发送 了ACK后，应用层通常就会检测到这个连接即将断开，然后被动断开的应用层调用close关闭连接。 我可以告诉你，一旦当你调用close(or closesocket)，这一端就会发送FIN报文。也就是说，现在被动 关闭的一端也发送FIN给主动关闭端。有时候，被动关闭端会将ACK和FIN两个报文合在一起发送。主动 关闭端收到FIN后也发送ACK，然后整个连接关闭(事实上还没完全关闭，只是关闭需要交换的报文发送 完毕)，四次握手完成。如你所见，因为被动关闭端可能会将ACK和FIN合到一起发送，所以这也算不上 严格的四次握手---四个报文段。 在前面的文章中，我一直没提TCP的状态转换。在这里我还是在犹豫是不是该将那张四处通用的图拿出来， 不过，这里我只给出断开连接时的状态转换图，摘自<The TCP/IP Guide>： 给出一个正常关闭时的windump信息： 14:00:38.819856 IP cd-zhangmin.1748 > 220.181.37.55.80: F 1:1(0) ack 1 win 65535 14:00:38.863989 IP 220.181.37.55.80 > cd-zhangmin.1748: F 1:1(0) ack 2 win 2920 14:00:38.864412 IP cd-zhangmin.1748 > 220.181.37.55.80: . ack 2 win 65535   补充细节： 关于以上的四次握手，我补充下细节： 1. 默认情况下(不改变socket选项)，当你调用close( or closesocket，以下说close不再重复)时，如果 发送缓冲中还有数据，TCP会继续把数据发送完。 2. 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。 3. 应用层如何知道对端关闭？通常，在最简单的阻塞模型中，当你调用recv时，如果返回0，则表示对端 关闭。在这个时候通常的做法就是也调用close，那么TCP层就发送FIN，继续完成四次握手。如果你不调用 close，那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。 4. 在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关 闭，你可以写代码试试。       特别的TIME_WAIT状态： 从以上TCP连接关闭的状态转换图可以看出，主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后， 会进入TIME_WAIT状态。TIME_WAIT状态也称为2MSL状态。 什么是2MSL？MSL即Maximum Segment Lifetime，也就是报文最大生存时间，引用<TCP/IP详解>中的话：“ 它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么，2MSL也就是这个时间的2倍。其实我觉得没 必要把这个MSL的确切含义搞明白，你所需要明白的是，当TCP连接完成四个报文段的交换时，主动关闭的 一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束。你可以写代码试试，然后用netstat查看下。 为什么需要2MSL？根据<TCP/IP详解>和<The TCP/IP Guide>中的说法，有两个原因： 其一，保证发送的ACK会成功发送到对方，如何保证？我觉得可能是通过超时计时器发送。这个就很难用 代码演示了。 其二，报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。直接引用<The TCP/IP Guide> 的说法：The second is to provide a “buffering period” between the end of this connection  and any subsequent ones. If not for this period, it is possible that packets from different  connections could be mixed, creating confusion. TIME_WAIT状态所带来的影响： 当某个连接的一端处于TIME_WAIT状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的 是，这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时，这意味着这个TCP 连接并没有断开(完全断开)，那么，如果你bind这个端口，就会失败。 对于服务器而言，如果服务器突然crash掉了，那么它将无法再2MSL内重新启动，因为bind会失败。解决这 个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。 对于TIME_WAIT的插曲： 当建立一个TCP连接时，服务器端会继续用原有端口监听，同时用这个端口与客户端通信。而客户端默认情况 下会使用一个随机端口与服务器端的监听端口通信。有时候，为了服务器端的安全性，我们需要对客户端进行 验证，即限定某个IP某个特定端口的客户端。客户端可以使用bind来使用特定的端口。 对于服务器端，当设置了SO_REUSEADDR选项时，它可以在2MSL内启动并listen成功。但是对于客户端，当使 用bind并设置SO_REUSEADDR时，如果在2MSL内启动，虽然bind会成功，但是在windows平台上connect会失败。 而在linux上则不存在这个问题。(我的实验平台：winxp, ubuntu7.10) 要解决windows平台的这个问题，可以设置SO_LINGER选项。SO_LINGER选项决定调用close时，TCP的行为。 SO_LINGER涉及到linger结构体，如果设置结构体中l_onoff为非0，l_linger为0，那么调用close时TCP连接 会立刻断开，TCP不会将发送缓冲中未发送的数据发送，而是立即发送一个RST报文给对方，这个时候TCP连 接就不会进入TIME_WAIT状态。 如你所见，这样做虽然解决了问题，但是并不安全。通过以上方式设置SO_LINGER状态，等同于设置SO_DONTLINGER 状态。 断开连接时的意外： 这个算不上断开连接时的意外，当TCP连接发生一些物理上的意外情况时，例如网线断开，linux上的TCP实现 会依然认为该连接有效，而windows则会在一定时间后返回错误信息。 这似乎可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。