TCP连接的三次握手--一次故障记录
- - CSDN博客系统运维推荐文章大家都知道tcp和udp协议，tcp可靠的网络传输协议，udp效率高但是不会进行传输确认，只有投递. 那么三次握手就是为了保证tcp的可靠传输，下边是用wireshark抓取一次失败的http请求的结果：. 首先TCP的三次握手是建立连接. NO1，113.31的主机给112.65的主机发送了一个包含syn的包并且设置seq等于0，来请求建立连接.
TCP连接的三次握手--一次故障记录
标签：
tcp
握手
记录
| 发表时间：2013-12-20 05:54 | 作者：caiwenguang1992
出处：http://blog.csdn.net
关于TCP的三次握手
大家都知道tcp和udp协议，tcp可靠的网络传输协议，udp效率高但是不会进行传输确认，只有投递。
那么三次握手就是为了保证tcp的可靠传输，下边是用wireshark抓取一次失败的http请求的结果：
首先TCP的三次握手是建立连接
NO1，113.31的主机给112.65的主机发送了一个包含syn的包并且设置seq等于0，来请求建立连接
NO2，112.65的主机给113.31的主机回复了一个syn+ack的包，并且seq也等于0，回复客户端，我同意建立请求
NO3，113.31的主机给112.65的主机回复了一个ack的确认包，并且设置seq=1， 告诉服务器，连接以成功建立
至于NO4的包，就是本次连接最关键的失败之处了
NO4，113.31因为某种原因给服务端发送了一个rst（reset）报文，也就是重置连接的报文。
NO5，仅接着113.31再次给服务器发送了一个HTTP的head请求，此时服务器便回复了客户端的rst报文
NO6，服务器给客户端也回复rst，就同意服务器同意了reset本次连接，导致连接断开！！！
curl错误结果如下：
[root@Cwg ~]# curl -I
http://www.testaaa.com/
curl: (56) Failure when receiving data from the peer
这个错误差了好长时间，就是不知道为什么，很明显NO4的报文和NO5的报文是冲突的，既然客户端首先提出重置连接，那么为什么后边还要搬起石头砸自己的脚发送一个http的head请求！！！
初步怀疑网络上可能有什么过滤设备导致的，但是客户的服务器也不得而知了，只能这么不了了之。
+++++++++
晚上回家后边走边想，如果客户端给服务器发送rst的包了之后为什么还要发送请求，这个问题有些想不通，然后再请求的时候客户端也抓包看看。。。
结果如下：
[root@Cwg ~]# tcpdump -vvXe host 112.65.X.X
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:24:36.947082 00:e0:4c:1c:1d:2a (oui Unknown) > 38:22:d6:a1:78:66 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 3092, offset 0, flags [DF], proto TCP (6), length 60)
188.188.3.240.a3-sdunode > www.testaaa.com.http: Flags [S], cksum 0xa4f2 (correct), seq 2466954207, win 14600, options [mss 1460,sackOK,TS val 949598155 ecr 0,nop,wscale 7], length 0
0x0000: 4500 003c 0c14 4000 4006 1a26 bcbc 03f0 E..<..@.@..&....
0x0010: 7041 e394 15e4 0050 930a bbdf 0000 0000 pA.....P........
0x0020: a002 3908 a4f2 0000 0204 05b4 0402 080a ..9............. //第一个包发送给服务器syn， flags 【s】就是sync，这个字段位标识了tcp的控制项下边再不多说
0x0030: 3899 b7cb 0000 0000 0103 0307 8...........
09:24:36.991519 38:22:d6:a1:78:66 (oui Unknown) > 00:e0:4c:1c:1d:2a (oui Unknown), ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 52, id 1216, offset 0, flags [none], proto TCP (6), length 52)
www.testaaa.com.http > 188.188.3.240.a3-sdunode: Flags [S.], cksum 0x429c (correct), seq 1671696166, ack 2466954208, win 16384, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
0x0000: 4500 0034 04c0 0000 3406 6d82 7041 e394 E..4....4.m.pA..
0x0010: bcbc 03f0 0050 15e4 63a4 0f26 930a bbe0 .....P..c..&.... //第二个包服务器发送给客户端syn+ack，这里的ack是ack 2466954208
0x0020: 8012 4000 429c 0000 0204 05b4 0103 0300 [email protected]...........
0x0030: 0101 0402 ....
09:24:36.991570 00:e0:4c:1c:1d:2a (oui Unknown) > 38:22:d6:a1:78:66 (oui Unknown), ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 3093, offset 0, flags [DF], proto TCP (6), length 40)
188.188.3.240.a3-sdunode > www.testaaa.com.http: Flags [.], cksum 0xc2f4 (correct), seq 1, ack 1, win 115, length 0
0x0000: 4500 0028 0c15 4000 4006 1a39 bcbc 03f0 E..(..@[email protected]....
0x0010: 7041 e394 15e4 0050 930a bbe0 63a4 0f27 pA.....P....c..' //客户端回复服务器ack，三次握手完成
0x0020: 5010 0073 c2f4 0000 P..s....
09:24:36.991639 00:e0:4c:1c:1d:2a (oui Unknown) > 38:22:d6:a1:78:66 (oui Unknown), ethertype IPv4 (0x0800), length 225: (tos 0x0, ttl 64, id 3094, offset 0, flags [DF], proto TCP (6), length 211)
188.188.3.240.a3-sdunode > www.testaaa.com.http: Flags [P.], cksum 0x6dfa (correct), seq 1:172, ack 1, win 115, length 171
0x0000: 4500 00d3 0c16 4000 4006 198d bcbc 03f0 E.....@.@.......
0x0010: 7041 e394 15e4 0050 930a bbe0 63a4 0f27 pA.....P....c..'
0x0020: 5018 0073 6dfa 0000 4845 4144 202f 2048 P..sm...HEAD./.H //控制端p表示是PDU分片
0x0030: 5454 502f 312e 310d 0a55 7365 722d 4167 TTP/1.1..User-Ag
0x0040: 656e 743a 2063 7572 6c2f 372e 3139 2e37 ent:.curl/7.19.7
0x0050: 2028 7838 365f 3634 2d72 6564 6861 742d .(x86_64-redhat-
0x0060: 6c69 6e75 782d 676e 7529 206c 6962 6375 linux-gnu).libcu
0x0070: 726c 2f37 2e31 392e 3720 4e53 532f 332e rl/7.19.7.NSS/3.
0x0080: 3134 2e30 2e30 207a 6c69 622f 312e 322e 14.0.0.zlib/1.2.
0x0090: 3320 6c69 6269 646e 2f31 2e31 3820 6c69 3.libidn/1.18.li
0x00a0: 6273 7368 322f 312e 342e 320d 0a48 6f73 bssh2/1.4.2..Hos
0x00b0: 743a 2077 7777 2e74 6573 7461 6161 2e63 t:.www.testaaa.c
0x00c0: 6f6d 0d0a 4163 6365 7074 3a20 2a2f 2a0d om..Accept:.*/*.
0x00d0: 0a0d 0a ...
09:24:37.236117 00:e0:4c:1c:1d:2a (oui Unknown) > 38:22:d6:a1:78:66 (oui Unknown), ethertype IPv4 (0x0800), length 225: (tos 0x0, ttl 64, id 3095, offset 0, flags [DF], proto TCP (6), length 211)
188.188.3.240.a3-sdunode > www.testaaa.com.http: Flags [P.], cksum 0x6dfa (correct), seq 1:172, ack 1, win 115, length 171
0x0000: 4500 00d3 0c17 4000 4006 198c bcbc 03f0 E.....@.@.......
0x0010: 7041 e394 15e4 0050 930a bbe0 63a4 0f27 pA.....P....c..'
0x0020: 5018 0073 6dfa 0000 4845 4144 202f 2048 P..sm...HEAD./.H //PDU分片
0x0030: 5454 502f 312e 310d 0a55 7365 722d 4167 TTP/1.1..User-Ag
0x0040: 656e 743a 2063 7572 6c2f 372e 3139 2e37 ent:.curl/7.19.7
0x0050: 2028 7838 365f 3634 2d72 6564 6861 742d .(x86_64-redhat-
0x0060: 6c69 6e75 782d 676e 7529 206c 6962 6375 linux-gnu).libcu
0x0070: 726c 2f37 2e31 392e 3720 4e53 532f 332e rl/7.19.7.NSS/3.
0x0080: 3134 2e30 2e30 207a 6c69 622f 312e 322e 14.0.0.zlib/1.2.
0x0090: 3320 6c69 6269 646e 2f31 2e31 3820 6c69 3.libidn/1.18.li
0x00a0: 6273 7368 322f 312e 342e 320d 0a48 6f73 bssh2/1.4.2..Hos
0x00b0: 743a 2077 7777 2e74 6573 7461 6161 2e63 t:.www.testaaa.c
0x00c0: 6f6d 0d0a 4163 6365 7074 3a20 2a2f 2a0d om..Accept:.*/*.
0x00d0: 0a0d 0a ...
09:24:37.279333 38:22:d6:a1:78:66 (oui Unknown) > 00:e0:4c:1c:1d:2a (oui Unknown), ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 52, id 1223, offset 0, flags [none], proto TCP (6), length 40)
www.testaaa.com.http > 188.188.3.240.a3-sdunode: Flags [R], cksum 0x9f93 (correct), seq 1671696167, win 0, length 0
0x0000: 4500 0028 04c7 0000 3406 6d87 7041 e394 E..(....4.m.pA.. //控制位R 表示reset连接 此处是服务器直接发送给客户端的，从开始到连接reset客户端只收到一个服务器发来的reset
0x0010: bcbc 03f0 0050 15e4 63a4 0f27 63a4 0f27 .....P..c..'c..'
0x0020: 5004 0000 9f93 0000 0000 0000 0000 P.............从开始到结束客户端只收到一个reset包，说明服务器受到的第4个rst包并非客户端所发，导致服务器响应了reset而过早结束连接！！！
客户的环境是win2003_32+IIS6,站点内容是纯静态页面
服务器系统层面以上的防护措施为了便于排错都关闭了，客户决定把站挪走，此次事件便成了一件悬案！！！
########################
迷途小运维随笔，转载请注明出处
作者：john
作者：caiwenguang1992 发表于2013-12-19 21:54:29 原文链接
阅读：23 评论：0 查看评论
相关 [tcp 握手 记录] 推荐：
TCP的三次握手以及TCP状态转换图详解
- - CSDN博客系统运维推荐文章今天来讨论一下TCP的三次握手以及TCP的状态转换图. 首先发一个三次握手的流程图如下：. 圖 2.4-3、三向交握之封包连接模式.
当用戶端想要对服务器端发起连接时，就必須要送出一個要求连线的封包，此时用戶端必须随机取用一個大于1024 以上的端口來做为程序通信的通道. 然后在 TCP 的表头当中，必须带有 SYN 的主动连线(SYN=1)，並并且记下发送给服务器端的序列号(Sequence number = 10001).
TCP/IP三次握手和HTTP过程
- - 互联网 - ITeye博客TCP/IP三次握手和HTTP过程. 原文地址：http://www.cnblogs.com/tiwlin/archive/2011/12/25/2301305.html. 手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接. TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上.
TCP协议缺陷不完全记录
- - BlogJava-首页技术区TCP自从1974年被发明出来之后，历经30多年发展，目前成为最重要的互联网基础协议. 有线网络环境下，TCP表现的如虎添翼，但在移动互联网和物联网环境下，稍微表现得略有不足. 移动互联网突出特性不稳定：信号不稳定，网络连接不稳定. 虽然目前发展到4G，手机网络带宽有所增强，但因其流动特性，信号也不是那么稳定：坐长途公交车，或搭乘城铁时，或周边上网密集时等环境，现实环境很复杂.
TCP连接状态异常记录
- - 非技术 - ITeye博客参考：http://blueskykong.com/2018/07/26/tcp-close-wait/. 分布式事务Lottor在测试环境中运行一段时间之后，出现Lottor客户端连接不上Lottor Server的情况. 经过排查，发现根源问题是Lottor客户端获取不到Lottor Server的集群信息.
TCP三次握手四次挥手详解
- - CSDN博客互联网推荐文章TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接. 1；建立连接时，客户端向服务器端发送一个SYN包，进入SYN_SEND状态，在该状态下，客户端等待服务器端的确认包. 2；服务器端收到客户端的SYN包后，首先向客户端确认自己已收到客户端的SYN包，同时也要发送自己的SYN包，即要向发送方发送ACK包+SYN包，然后进入SYN——RECEIVE状态.
转载:Wireshark基本介绍和学习TCP三次握手
- - 互联网 - ITeye博客Wireshark基本介绍和学习TCP三次握手. 用 Fiddler 来调试HTTP，HTTPS. 这篇文章介绍另一个好用的抓包工具wireshark， 用来获取网络数据封包，包括http,TCP,UDP，等网络协议包. 记得大学的时候就学习过TCP的三次握手协议，那时候只是知道，虽然在书上看过很多TCP和UDP的资料，但是从来没有真正见过这些数据包， 老是感觉在云上飘一样，学得不踏实.
[原]结合wireshark分析TCP和三次握手原理
- - HelloWorld一、wireshark介绍. wireshark数据包分析实战（第二版）电子书：
http://pan.baidu.com/s/1LCZV 提取密码： fqcv.
Wireshark（前称Ethereal）是一个 网络封包分析 软件. 网络封包分析 软件的功能是撷取 网络封包，并尽可能显示出最为详细的网络封包资料.
TCP 三次握手原理，你真的理解吗？
- -阿里妹导读：最近，阿里中间件小哥哥蛰剑碰到一个问题——client端连接服务器总是抛异常. 在反复定位分析、并查阅各种资料文章搞懂后，他发现没有文章把这两个队列以及怎么观察他们的指标说清楚. 因此，蛰剑写下这篇文章，希望借此能把这个问题说清楚. 场景：JAVA的client和server，使用socket通信.
tcp/ip调优
- Lucseeker - 在路上在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接. 第一次握手：建立连接时，客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；.