分析tcp报文
http://hi.baidu.com/nostop/blog/item/ffc0d358d4fa5a97800a18f9
tcpdump -i eth0 port 80 and host 10.6.48.137 -X
http://hi.baidu.com/nostop/blog/item/ce765b826cf3e6b40cf4d2f9
11种状态 ：
http://hi.baidu.com/smilehaha/blog/item/b4e16ca81bdeafa6cb130cfe
摘自：http://blog.csdn.net/lmsnju/article/details/4916229
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如图1所示。
（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。
（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。
（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据。
由于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）。
TCP采用四次挥手关闭连接如图2所示。
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报文。
摘自：http://blog.csdn.net/eroswang/article/details/3080217
简述TCP协议连接建立时3次握手的过程。
根据TCP头部，说明下列3个包在连接建立过程中的次序.
0020
0030
0040
0020
0030
0040
0020
0030
0040
解：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
1）是第二次握手，flags位上为12，二进制是00010010，即表示有syn和ack.
2）是第一次握手，flags位上为02，二进制是00000010，即表示有syn没有ack。
3）是第三次握手，flags位上为10，二进制是00010000，即表示有ack没有syn。
该连接访问的是80端口，是为HTTP（HyperTextTransportProtocol，超文本传输协议）开放的，
第一次握手：建立连接时，客户端发送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(orclosesocket)之类 当被动关闭的一方收到FIN报文时，它会发送ACK确认报文(对于ACK这个东西你应该很熟悉了)。这里有个 我可以告诉你，一旦当你调用close(orclosesocket)，这一端就会发送FIN报文。也就是说，现在被动 在前面的文章中，我一直没提TCP的状态转换。在这里我还是在犹豫是不是该将那张四处通用的图拿出来，
给出一个正常关闭时的windump信息： ![[转载]TCP协议连接建立时3次握手的过程4次结束连接](http://www.cppblog.com/Images/OutliningIndicators/None.gif "[转载]TCP协议连接建立时3次握手的过程4次结束连接") 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
补充细节： 关于以上的四次握手，我补充下细节：
特别的TIME_WAIT状态： 从以上TCP连接关闭的状态转换图可以看出，主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后， 什么是2MSL？MSL即Maximum SegmentLifetime，也就是报文最大生存时间，引用<TCP/IP详解>中的话：“ 为什么需要2MSL？根据<TCP/IP详解>和<TheTCP/IP Guide>中的说法，有两个原因： TIME_WAIT状态所带来的影响： 当某个连接的一端处于TIME_WAIT状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的 对于服务器而言，如果服务器突然crash掉了，那么它将无法再2MSL内重新启动，因为bind会失败。解决这 对于TIME_WAIT的插曲： 当建立一个TCP连接时，服务器端会继续用原有端口监听，同时用这个端口与客户端通信。而客户端默认情况 对于服务器端，当设置了SO_REUSEADDR选项时，它可以在2MSL内启动并listen成功。但是对于客户端，当使 要解决windows平台的这个问题，可以设置SO_LINGER选项。SO_LINGER选项决定调用close时，TCP的行为。 如你所见，这样做虽然解决了问题，但是并不安全。通过以上方式设置SO_LINGER状态，等同于设置SO_DONTLINGER 断开连接时的意外： 这似乎可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。 |
![[转载]TCP协议连接建立时3次握手的过程4次结束连接](http://www.vimer.cn/wp-content/uploads/2009/11/4036295646_eb2b2b957d.jpg "[转载]TCP协议连接建立时3次握手的过程4次结束连接")
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
