对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）

重要 !!!!!!!!! 转载自[怀揣梦想,努力前行]

基础请查看 ----------> [tcp基础]

如果你正在读这篇文章，很可能你对TCP“非著名”的“三次握手”或者说“SYN,SYN/ACK,ACK”已经很熟悉了。不幸的是，对很多人来说，对TCP的学习就仅限于此了。尽管年代久远，TCP仍是一个相当复杂并且值得研究的协议。这篇文章的目的是让你能够更加熟练的检查Wireshark中的TCP序列号和确认号

在我们开始之前，确保在Wireshark中打开示例（请到作者原文中下载）并亲自实践一下

示例中仅包含一个单独的HTTP请求，请求的流程是：web浏览器向web服务器请求一个单独的图片文件，服务器返回一个成功的响应（HTTP/1.1200 OK），响应中包含请求的文件。右键示例文件中任意一个TCP包并且选择Follow TCP Stream就可在单独的窗口查看原始的TCP流

客户端请求使用红色显示，服务端响应使用蓝色显示

TCP三次握手（参见：http://blog.csdn.net/a19881029/article/details/30241561）

TCP在其协议头中使用大量的标志位或者说1位（bit）布尔域来控制连接状态，我们最感兴趣的3个标志位如下：

SYN - 创建一个连接

FIN - 终结一个连接

ACK - 确认接收到的数据

就像我们看见的那样，一个包中有可以设置多个标志位

选择Wireshark中的“包”1并且展开中间面板的TCP层解析，然后展开TCP头中的标志位域，这里我们可以看见所有解析出来的TCP标志位，需要注意的是，“包1”设置了SYN标志位

使用同样的方式操作“包2”。可以看到"包2"设置了2个标志位：ACK - 用来确认收到客户端的SYN包，SYN - 用来表明服务端也希望建立TCP连接

从客户端发来的“包3”只设置了ACK标志位。这3个包完成了最初的TCP3次握手

序列号和确认号：

TCP会话的每一端都包含一个32位（bit）的序列号，该序列号被用来跟踪该端发送的数据量。每一个包中都包含序列号，在接收端则通过确认号用来通知发送端数据成功接收

当某个主机开启一个TCP会话时，他的初始序列号是随机的，可能是0和4,294,967,295之间的任意值，然而，像Wireshark这种工具，通常显示的都是相对序列号/确认号，而不是实际序列号/确认号，相对序列号/确认号是和TCP会话的初始序列号相关联的。这是很方便的，因为比起真实序列号/确认号，跟踪更小的相对序列号/确认号会相对容易一些

比如，在“包1”中，最初的相对序列号的值是0，但是最下方面板中的ASCII码显示真实序列号的值是0xf61c6cbe，转化为10进制为4129057982

如果想要关闭相对序列号/确认号，可以选择Wireshark菜单栏中的 Edit -> Preferences ->protocols ->TCP，去掉Relative sequence number后面勾选框中的√即可

需要注意的是，文章接下来的部分依然使用相对序列号/确认号

为了更好的理解在整个TCP会话期间，TCP序列号和确认号是如何工作的，我们可以使用Wireshark内置的绘制流功能，选择菜单栏中的 Statistics ->Flow Graph...->TCP flow ->OK

Wireshark会自动创建一个TCP流的图形摘要

每行代表一个单独的TCP包，左边列显示时间，中间列显示包的方向、TCP端口、段长度和设置的标志位，右边列以10进制的方式显示相关序列号/确认号，在这里选中任意行会高亮主窗口中该行所关联的包

我们可以利用这个流图更好的理解序列号和确认号是如何工作的

包1：

TCP会话的每一端的序列号都从0开始，同样的，确认号也从0开始，因为此时通话还未开始，没有通话的另一端需要确认（我使用的Wireshark版本和原作者不同，Wireshark1.10.2中，包1不显示确认号）

包2：

服务端响应客户端的请求，响应中附带序列号0（由于这是服务端在该次TCP会话中发送的第一个包，所以序列号为0）和相对确认号1（表明服务端收到了客户端发送的包1中的SYN）

需要注意的是，尽管客户端没有发送任何有效数据，确认号还是被加1，这是因为接收的包中包含SYN或FIN标志位（并不会对有效数据的计数产生影响，因为含有SYN或FIN标志位的包并不携带有效数据）

包3：

和包2中一样，客户端使用确认号1响应服务端的序列号0，同时响应中也包含了客户端自己的序列号（由于服务端发送的包中确认收到了客户端发送的SYN，故客户端的序列号由0变为1）

此时，通信的两端的序列号都为1，通信两端的序列号增1发生在所有TCP会话的建立过程中

包4：

这是流中第一个携带有效数据的包（确切的说，是客户端发送的HTTP请求），序列号依然为1，因为到上个包为止，还没有发送任何数据，确认号也保持1不变，因为客户端没有从服务端接收到任何数据

需要注意的是，包中有效数据的长度为725字节

包5：

当上层处理HTTP请求时，服务端发送该包来确认客户端在包4中发来的数据，需要注意的是，确认号的值增加了725（725是包4中有效数据长度），变为726，简单来说，服务端以此来告知客户端端，目前为止，我总共收到了726字节的数据，服务端的序列号保持为1不变

包6：

这个包标志着服务端返回HTTP响应的开始，序列号依然为1，因为服务端在该包之前返回的包中都不带有有效数据，该包带有1448字节的有效数据

包7：

由于上个数据包的发送，TCP客户端的序列号增长至726，从服务端接收了1448字节的数据，客户端的确认号由1增长至1449

在抓包文件的主体部分，我们可以看到上述过程的不断的重复，客户端的序列号一直是726，因为客户端除了最初的725字节数据没有再向服务端发送数据，服务端的序列号则与此相反，由于服务端不断的发送HTTP响应，故其序列号一直在增长

序列号为当前端成功发送的数据位数，确认号为当前端成功接收的数据位数，SYN标志位和FIN标志位也要占1位

关闭连接

包38：

在确认了服务端发送过来的最后一个数据段之后，客户端将处理整个HTTP响应并决定不需要进一步通信了。此时客户端发送设置了FIN标志位的包38，其确认号和之前的包37一样

包39：

服务端通过将确认号加1的方式回应客户端期望关闭连接的请求（这里和包2中确认SYN标志位时所作的操作是一样的），同时设置当前包的FIN标志位

包40：

客户端发送最终序列号727，通过将确认号加1的方式确认服务端的FIN包

此时，通信双方都终结了会话并且可以释放用于维持会话所占用的资源

对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）相关推荐

TCP 三次握手过程详解
TCP(Transmission Control Protocol) 传输控制协议 TCP:面向连接的,可靠的,基于字节流的传输层通信协议 TCP(传输层)位于IP层(网络层)之上,应用层之下,不同的 ...
TCP三次握手原理详解
TCP/IP协议不是TCP和IP这两个协议的合称,而是指因特网整个TCP/IP协议族. 从协议分层模型方面来讲,TCP/IP由四个层次组成:网络接口层.网络层.传输层.应用层. TCP协议:即传输控制 ...
TCP 三次握手原理，你真的理解吗
转载自 TCP 三次握手原理,你真的理解吗最近,阿里中间件小哥哥蛰剑碰到一个问题--client端连接服务器总是抛异常.在反复定位分析.并查阅各种资料文章搞懂后,他发现没有文章把这两个队列以及怎么 ...
计算机网络学习笔记（七）——传输层、TCP三次握手、四次挥手、TCP流量控制、大总结
文章目录前言概念一.传输层概述二.传输层问题三.端到端寻址四.TCP三次握手和四次挥手 (一)三次握手建立连接 (二)四次挥手拆除连接五.带拥塞的TCP流量控制六.传输层实例计网大总 ...
TCP 三次握手原理，你真的理解吗？
阿里妹导读:最近,阿里中间件小哥哥蛰剑碰到一个问题--client端连接服务器总是抛异常.在反复定位分析.并查阅各种资料文章搞懂后,他发现没有文章把这两个队列以及怎么观察他们的指标说清楚. 因此,蛰剑 ...
TCP、UDP、TCP三次握手与四次挥手、TCP如何保证可靠传输、TCP异常分析、拆包和粘包等
4.OSI模型 4.1.OSI七层模型 4.2.七层模型功能物理层:利用传输介质为数据链路层提供物理连接,实现比特流的透明传输,如网线:网卡标准. 数据链路层:接收来自物理层的位流形式的数据 ...
TCP协议：三次握手过程详解
本文通过图来梳理TCP-IP协议相关知识.TCP通信过程包括三个步骤:建立TCP连接通道,传输数据,断开TCP连接通道.如图1所示,给出了TCP通信过程的示意图. 上图主要包括三部分:建立连接.传输数 ...
java socket 握手_TCP建立连接三次握手过程详解(wireshark截图、java socket源码)
TCP(Transmission Control Protocol传输控制协议)是一种面向连接的.可靠的.基于字节流的传输层通信协议. 三次握手协议建立连接图握手过程步骤如下(配wireshark分 ...
java tcp 三次握手_用Java代码分析TCP的三次握手四次挥手过程
(1)客户端发送一个带SYN标志的TCP报文到服务器.这是三次握手过程中的报文1. (2) 服务器端回应客户端的,这是三次握手中的第2个报文,这个报文同时带ACK标志和SYN标志.因此它表示对刚才客户 ...

对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）

对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）相关推荐

最新文章

热门文章

对tcp三次握手的详解之 理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）

对tcp三次握手的详解之 理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）相关推荐

最新文章

热门文章

对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）

对tcp三次握手的详解之理解TCP序列号（Sequence Number）和确认号（Acknowledgment Number）相关推荐