TCP/IP协议族详解（五）

23 Mar 2018 6478字 22分
CC BY 4.0 （除特别声明或转载文章外）

本系列文章是教程：TCP、IP协议族详解的学习笔记。

该系列大概分为下面几个部分：

  • 1、TCP/IP协议4层结构以及每层的作用
  • 2、IP协议详解
  • 3、ARP协议和RARP协议详解
  • 4、ICMP协议详解
  • 5、TCP协议详解
  • 6、UDP协议详解

本文主要介绍 TCP/IP 网络体系中网络层的 TCP 协议。另外推荐一篇文章，写得很不错。

在介绍 TCP 协议之前，让我们先了解一下传输层。

1、网络层与传输层关系

先举一个生活中的例子，假如我在京东上购买了一个物品，发货方为上海的某个商家，收货方就是我的公司地址，比如说是：双击省老铁市666区没毛病软件园A座。 但是A座这栋楼很大，快递员不知道我具体在哪一层哪个室，这里就需要一个门牌号，比如说666号。

那么，套路上面的例子，双击省老铁市666区没毛病软件园A座这个地址就类似IP地址，它工作于网络层， 它能定位到一块具体的位置，也是就 A 座这台电脑，在 A 座这栋楼里面的各个公司就是计算机中的各个进程，每个公司（进程）都占有一个门牌号， 这个门牌号就是端口号，端口号这个概念就属于传输层。

两台主机间通信条件：

  1. 本地主机 IP
  2. 远程主机 IP

两台主机进程间通信条件：

  1. 本地主机 IP
  2. 本地进程 端口
  3. 远程主机 IP
  4. 远程进程 端口

因此，可以简单的理解：网络层（这里指 IP 协议）提供主机之间的逻辑通信，传输层（这里指 TCP 或者 UDP 协议）提供提供进程之间的逻辑通信。

2、传输层协议详解

传输层功能

  • 分段及封装应用层送来的数据，例如：我们运送水果，不可能一个一个的运送，一般都是将大堆苹果装车后一车一车的运送， 每一车装多少个就是分段数据，装车后要用布封起来保鲜就是封装数据。
  • 提供端到端的传输服务，即源主机端口到目的主机端口进行通信。
  • 在发送主机与接收主机之间构建逻辑通信，如果源主机分别开启Telnet、http访问远程主机的telnet服务和http服务， 那么传输层就提供这样一个机制，它构建了两个对应的逻辑通道。

关于端口

端口

端口的范围

端口的大小目前是2个byte，也就是说最大有 65536 个端口，在 0~65535 这个范围内，我们又把它分成三个部分：

  • 熟知端口(著名端口)：0-1023，由ICANN指派和控制（例如：80 端口、22 端口等）
  • 注册端口：1024-49151,IANA不指派也不控制，但须注册（例如：3306 端口，即 mysql 端口）
  • 动态端口(短暂端口)：49152-65535，IANA 不指派也不控制，无须注册，可以分配给你自己的应用

3、TCP协议详解

核心：TCP 协议负责将数据分段成 TCP 报文段(每一段报文作为传递给 IP 层的数据)、重组 TCP 报文段将数据还原。

TCP协议的特点

  • 面向连接：通讯双方交换数据之前必须要先建立连接
  • 可靠性：提供了多种确保可靠性的机制
  • 字节流服务：8bit（1byte）为最小单位构成的字节流（所以不存在粘包的概念）

套接字

套接字（socket）它是ip地址和端口号的一个组合（例如：192.168.2.172:80），它是TCP连接的最基本的、抽象化的一个对象， 也就是TCP连接的端点，一个 TCP 连接有两个端点。

socket套接字

TCP数据传输过程

在底层的实现中，TCP发送端和接收端都有对应的缓存，分别是发送缓存、接收缓存，应用层传递给传输层的数据并不一定立即就发送出去了， 而是先放入缓存中，然后等待最合适的时机（网络通畅、对端用空闲等等）再把数据发送出去。同理，接收端也是一样的道理。

另外，需要注意，传输层在向 IP 层传递数据是，是以分组为单位的，而不是按整个字节流来发送，TCP 协议把若干字节构成一个分组后， 再投递给 IP 层，这种的分组就称为报文段（Segment），因此，我们常常说 TCP 报文段就是这样来的。

举例来说：我去菜市场买了一根很长的黄瓜（现在的黄瓜怎么都长那么长- -），太长不好切，那就先把黄瓜切成一段一段的， 然后再对每一段切片。这个切成一段的过程就类似 TCP 数据分段，分段后再交给 IP 层。

TCP数据传输

让我们在深入一层，拿上图来说，首先我们要知道两个概念：字节号和报文段序号。

  • 字节号，就是上图中环形缓存中未发送的字节，每个字节所对应的编号（一个格子表示一个字节），字节号的范围是（0~2^32-1），生成方式随机（依赖于系统内核的实现方式）。 例如：要发送一个6000byte的数据，并且给第一个字节随机到了一个字节号为1057，那么这6000个字节的数据所对应的字节号就是：1057~7056

  • 报文段序号，它是基于前面的字节号，其实就是分段后，第一个字节的字节号 例如：把上面的6000字节的数据分为5个报文发送，前4个报文每个发送1000个字节，最后一个发送2000个字节。那么这5个报文段的序号依次是：1057、2056、3056、4056、5056。

4、TCP报文段首部格式

它与IP协议首部格式类型，也分为固定部分（20byte）和可选部分。

TCP首部格式

和前面一样，通过抓包来逐个解释每个字段。这里访问一个网站，抓包结果如下： TCP首部抓包结果

上面两个结果是一次TCP通讯的往返信息，下面以上图中第三个包作为例子解释各个字段：

  • 第1、2个字节：值为dc ea，十进制为56554，表示源端口，一般如果源端没有bind一个端口的话，这个端口将是动态的，比如我们访问一个http网站，第一次访问可能是56554，刷新网页后端口可能就发生了变化。
  • 第3、4个字节：值为00 50，十进制为80（也就是大家熟悉的http服务端口），表示目的端口。 注意一下这里的Stream index:1，可以看做成一个五元组(源IP、源端口、目的IP、目的端口、传输协议)的编号，只要其中一个发送变化，这个流索引号就会发生变化。 另外，这里有个TCP segment Len:0，表示这个报文没有传递数据，因为上图抓的是三次握手的包，所以没有数据长度。
  • 第5到8个字节：表示报文段序号（图中显示的是相对位置，至于相对位置和绝对段序号是怎么转换的，我暂时也不太清楚，这里留一个疑问）

  • 第9到12个字节：表示确认号，也是相对序号（三次握手），即告诉对方我期望收到你的下一个报文段的序号值。 比如发送的报文段A的序号是100，那么对端收到后确认，并要求你下一个发送的报文段的序号要为100+1=101，这个101就在对端返回的报文段B中的确认号部分。同理，发送端对接收端的数据也要做确认。

    流程如下：

      发送端 ----         报文A(序号100)          ---> 接收端
  发送端 <---     报文B(序号200,确认号101)     ---- 接收端
  发送端 ----下一个数据报文段(序号101,确认号201) ---> 接收端

  • 第13、14个字节：这里需要特殊处理一下：

    • 前4bit表示首部长度，和IP首部一样，也是以4字节为单位（所以tcp头部最大为15*4=60byte）；
    • 后12个bit中，只用到后面6bit，前面的保留（不过现在也有用到前面的bit位了），关于后6个bit每位表达的意义，后面做详细介绍
  • 第15、16个字节:表示窗口大小，最大是65536个字节，也就是64kb。 注意：这个值很重要，下面会有窗口机制的详细介绍。
  • 第17、18个字节：校验和，它校验的范围包括tcp首部和数据两个部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部（伪首部就是ip地址）。
  • 第19、20个字节：紧急指针，紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。同时 URG比特位要置1。

  • 可选选项：主要介绍MSS（maximum Segment Size）,它用来限定TCP报文段数据部分的最大长度，不包含TCP首部。 这里要只要MTU（ Maximum Transmit Unit）这个概念，即最大传输单元，是物理接口（数据链路层）提供给其上层（IP层）最大一次能传输的数据大小，以以太网为例，缺省MTU=1500byte，这是以太网接口对IP层的约束。 例如：IP层有<=1500byte的字节要发送，则只需要一个IP包就可以发送了，如果>1500byte，就需要IP层分片，每个分片有相同的IP首部。

    一般情况下，有以下等式：

    MSS = MTU-TCP首部（20byte）-IP首部（byte）

6bits 每个比特位介绍：

  • 紧急比特 URG： 当 URG=1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。
  • 确认比特 ACK： 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效
  • 推送比特 PSH (Push): 接收 TCP 收到推送比特置 1 的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。
  • 复位比特 RST (Reset)： 当 RST=1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接
  • 同步比特 SYN: 同步比特 SYN 置为 1，就表示这是一个连接请求或连接接受报文，一般是tcp建立连接的第一个tcp报文。
  • 终止比特 FIN (Final)： 用来释放一个连接。当FIN = 1 时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。一般是tcp终止连接的最后一个报文。

5、TCP三次握手

tcp使用三次握手机制建立TCP连接，三次握手流程如下： TCP三次握手

下面详解讲解这三个过程：

  • 连接发起方首先发送一个 SYN，SEQ=X（这个报文的序号是系统随机的），发送的报文A: SYN，SEQ=X（假如X=1000）
  • 接收方收到SYN后，会确认这个SYN，并返回SYN+ACK，它确认发送方的SYN，同时也会向发送方也发送一个SYN确认请求，而且还会告知对方，我的窗口大小（可以理解成能接受数据的缓存的大小）。 返回的报文B：SEQ=Y(假如Y=5000)，SYN，ACK=X+1（也就是报文A的SEQ+1 = 1001）
  • 发起方收到接受方的SYN+ACK后，也会对对方的SYN确认，同时也会告知我的窗口大小。 返回的报文C：SEQ=1001，ACK=Y+1(也就是报文B的SEQ+1=5001)

三次握手就是一个“礼尚往来”的过程。比如说：小明有2个苹果，小红有2个梨子，他俩都想要吃对方的水果，那么用三次握手解释如下：

  • 小明给了小红一个苹果，用来搭讪，小明：“给你一个苹果，可好吃了”（SEQ=苹果1）
  • 小红吃了一个苹果后，觉得很好吃，于是给了小明一个梨子作为回礼，但是小红还想继续吃，就撒娇说：“人家还想吃苹果”（SEQ=梨子1，ACK=苹果2）
  • 小明一听，哟，有戏啊，于是就把最后的一个苹果给了小红，同时又跟小红说：“要不你把最后那个梨子也给我吧”（SEQ=苹果2，ACK=梨子2）

于是小明和小红就勾搭上了，从此性福快乐的在一起了。

6、TCP四次挥手

tcp使用四次挥手机制终止TCP连接，四次挥手流程如下： TCP四次挥手

下面详解讲解这四个过程：

  • 客户方起方首先发送一个FIN，SEQ=X（这个报文的序号是系统随机的）。 发送的报文A: SYN，SEQ=X（假如X=1000）
  • 服务方收到FIN后，会确认这个FIN，并返回ACK，但是这里并没有立即返回FIN给客户方，此时，只能说客户方到服务方的连接释放了，这个TCP连接处于“半关闭”状态，服务方还是能否传送数据到客户方，反之不行。 返回的报文B：SEQ=Y(假如Y=5000)，ACK，ACK=X+1（也就是报文A的SEQ+1 = 1001）
  • 一段时间后，服务方才发送FIN给客户方，通知客户方，我也要终止连接了。 发送的报文C：SEQ=Z(假如Z=7000)，FIN，ACK，ACK=X+1(也就是报文A的SEQ+1=1001)
  • 最后，客户端确认服务方发送过来的FIN，此时，这个TCP连接就完全终止了。 返回的报文D：ACK，SEQ=X+1(1001)，ACK=Z+1（7001）

还是上面的例子，小红和小明勾搭一段时间后，小明要分手，分手前决定把之前交换的水果都还回去。

  • 小明（客户方）还了一个梨子给小红，并且提出了分手(SEQ=梨子1)
  • 小红答应了，也还了一个苹果给小明，并且要求把最后的梨子也换回来(SEQ=苹果1,ACK=梨子2)
  • 小明在之前吃了一个梨子，发现没有梨子了，就假装没反应，心里寻思着去哪里弄个梨回来，这时候小红又发来通告，“赶紧还我例子，还了赶紧分手”(SEQ=苹果1,ACK=梨子2,FIN)
  • 小明最终搞到一个梨子，并还给了小红，同时要求小红还最后的苹果(SEQ=梨子2,ACK=苹果2)

从此，二人分道扬镳。

7、TCP确认和窗口机制

确认机制

假如要发送一批TCP报文，每个报文的SN（Sequence number）分别为：1，235，790,1500，当发送790这个报文的时候， 对方通过校验和检测，发现数据错误，就会返回一个带ACK的报文，且ACK id = 790，要求发送方重新发送一次790，这就是TCP重传确认机制。 TCP的报文到达确认（ACK），是对接收到的数据的最高序列号的确认，并向发送端返回一个下次接收时期望的TCP数据包的序列号（Ack Number） （注意：这里一定要理解好ACK以及ACK number的意义）。例如，主机A发送的当前数据序号是400，数据长度是100， 则接收端收到后会返回一个确认号是501的确认号给主机A。

举一个例子：

假如要发送1000字节的数据，tcp分片后假设有5个分片，分别是：

  • 第1个分片：1-200，共200字节
  • 第2个分片：201-400，共200字节
  • 第3个分片：401-700，共300字节
  • 第4个分片：701-900，共200字节
  • 第5个分片：901-1000，共100字节

当发送方发送了1、2、3个分片后，接收方确实时，发现第2个包出现错误，就会返回一个ack包（ack number=2），发送方收到这个ack包后， 对比它自己的最高序列号，发现2小于3，就认为是第2个分片错误，需要重传，然后发送方就会重传第2个分片。

TCP提供的确认机制，可以在通信过程中可以不对每一个TCP数据包发出单独的确认包（Delayed ACK机制）， 而是在传送数据时，顺便把确认信息传出，这样可以大大提高网络的利用率和传输效率。 同时，TCP的确认机制，也可以一次确认多个数据报，例如，接收方收到了201，401，701的数据报， 则只需要对701的数据包进行确认即可，对701的数据包的确认也意味着701之前的所有数据包都已经确认，这样也可以提高系统的效率。

窗口机制

tcp利用窗口大小进行流量控制，一般情况下，它是由数据接收端定义的。它用来控制对方发送的数据量，单位为字节。 TCP 连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。

来举一个例子：有个水池，水池有进水口和出水口，进水的管子根据粗细分为很多根，通过水池现在的空闲大小， 我们要动态计算需要用哪种粗细的管子来加水。如果水池现在没水了，就要用更粗一点的管子，同时供水方就加大供水， 如果水池快满了，就要切换成细一点的管子，并通知供水方减小供水。 那么上面的水池就是tcp缓存，粗细不同的管子就是就类似是窗口大小，通过窗口大小来达到流量控制的目的。

其实TCP在整个发送过程中，也在度量当前的网络状态，目的是为了维持一个健康稳定的发送过程，比如拥塞控制。 因此，数据是在某些机制的控制下进行传输的，就是窗口机制。发送端的发送窗口是基于接收端的接收窗口来计算的。

下图可以生动描述窗口机制的工作原理： TCP窗口机制

我们把上面的数据分为四种类型：

  1. 已经发送且对端已经确认
  2. 已发送，对端等待确认（此时还在窗口内）
  3. 在窗口内，但未发送
  4. 在窗口外，未发送

TCP窗口就是这样逐渐滑动，发送新的数据，滑动的依据就是发送数据已经收到ACK，确认对端收到，才能继续窗口滑动发送新的数据。 可以看到窗口大小对于吞吐量有着重要影响，同时ACK响应与系统延时又密切相关。

需要说明的是：如果发送端的窗口过大会引起接收端关闭窗口，处理不过来。 反之，如果窗口设置较小，结果就是不能充分利用带宽，所以仔细调节窗口对于适应不同延迟和带宽要求的系统很重要。

关于TCP的窗口机制，可以参考博客TCP 协议中的 Window Size与吞吐量。