抓包演示TCP协议的三次握手过程..doc

抓包演示TCP协议的三次握手过程 Written by Allen Iversion 三次握手原理 第一次握手： 客户端向服务器问好，问咱俩能不能通信，并告知服务器自己的序列号为x，其中x为机器随机产生的一个数字。 第二次握手： 服务器收到来自客户端的序列号x，当服务器认为可以与客户端通信，就发出回应，置确认号为x+1，并告知客户端自己的序列号为y，其中y也是随机生成。 第三次握手： 客户端接收到来自服务器的确认号x+1时，知道服务器答应与自己通讯了，于是置下一次正式传输数据开始的序列号为x+1，同时置确认号为y+1，表示告知服务器我收到你的应答了，数据传输可以开始。 三次握手与现实生活中的预约很相似。客人问主人有没有空接收来访，主人回应客户有空就允许客户来访。当然，计算机世界里更文明，主人回应有空的同时还会问客户什么时候方便来访。经过三次的沟通，大家才达成最后的约定。 抓包演示TCP三次握手 下面使用抓包软件捕捉一次访问网页时的数据包。其中本机地址是0，访问网页使用的是HTTP协议，而HTTP协议是基于TCP协议的。 TCP数据包格式 注意，TCP协议的数据请求分为三次握手和数据正式传输。在正式传输数据之前，三次握手的数据包是没有内容的。 三次握手过程中的数据包（DATA部分没有内容），下面是示例 数据传输时的数据包（包含HTTP协议的内容）： 第一次握手 看第一个数据包： 源：0:2845——目的：37:80 序列号=0489031834,确认号=0000000000 第二次握手 第二个数据包： 源：37:80 ——目的：0:2845 序列号=1527084646,确认号=0489031835（这时看到服务器回应的确认号=上一次握手客户端发过来序号+1=0489031834+1） 第三次握手 第三次握手的数据包： 源0:2845——目的：37:80 序列号=0489031835,确认号=1527084647（这时看到本机回应的确认号=上一次握手服务器发过来序号+1=1527084646+1） 数据正式传输 握手完成后，就开始正式传输数据了。下面是本机向服务器发出HTTP GET请求的数据包。 第四次数据包： 源：0:2845——目的：37:80 序列号：489031835 确认号：1527084647 备注：这里看到，正式请求数据时，本机使用的是第三次握手生成的序列号和确认号。 第五次数据包——服务器对第四次数据包的回应： 这时看到服务器对客户端的HTTP GET请求有回应的数据包，其中 源：37:www-http——目的：0:2845 序列号=1527084647（服务器使用客户端第四次数据包的确认号作为序列号） 确认号=0489032985（这里的确认号是第四次客户端的序列号489031835+HTTP包的长度1150=0489032985.） 备注：服务器可以预测下一次序列号seq，因为当前seq加上包体长度即为下一次seq，若下一次客户端请求数据包中的序列号不为该值，表示该数据包非法。通过序列号和确认号的机制，可以防止数据被挟持的风险。 但这里也看到，TCP协议的每一次数据传输都包含请求与确认，虽然保证了传输可靠性，但与UPD相比效率要低。UPD是另一话题，这里就不详细介绍了。  IP包内的协议字段，6表示走的是TCP协议 HTTP包体的内容，长度为1150字节