网络原理-计算机网络详解-传输层之TCP协议

一、TCP 协议的作用

互联网由TCP/IP协议族构成。TCP 只是其中的一层，有着自己的分工。

（图片说明：TCP 是以太网协议和 IP 协议的上层协议，也是应用层协议的下层协议。）

最底层的以太网协议（Ethernet）规定了电子信号如何组成数据帧（frame），解决了子网内部的点对点通信。

（图片说明：以太网协议解决了局域网的点对点通信。）

但是，以太网协议不能解决多个局域网如何互通，这由 IP 协议解决。

（图片说明：IP 协议可以连接多个局域网。）

IP 协议定义了一套自己的地址规则，称为 IP 地址。它实现了路由功能，允许某个局域网的 A 主机，向另一个局域网的 B 主机发送消息。

（图片说明：路由器就是基于 IP 协议。局域网之间要靠路由器连接。）

路由的原理很简单。市场上所有的路由器，背后都有很多网口，要接入多根网线。路由器内部有一张路由表，规定了 A 段 IP 地址走出口一，B 段地址走出口二，……通过这套”指路牌”，实现了数据包的转发。

（图片说明：本机的路由表注明了不同 IP 目的地的数据包，要发送到哪一个网口（interface）。）

IP 协议只是一个地址协议，并不保证数据包的完整。如果路由器丢包（比如缓存满了，新进来的数据包就会丢失），就需要发现丢了哪一个包，以及如何重新发送这个包。这就要依靠 TCP 协议。

简单说，TCP 协议的作用是，保证数据通信的完整性和可靠性，防止丢包。

二、TCP 报文段的大小

MTU最大传输单元，这个最大传输单元实际上和链路层协议有着密切的关系，EthernetII帧的结构DMAC+SMAC+Type+Data+CRC由于以太网传输电气方面的限制，每个以太网帧都有最小的大小64bytes最大不能超过1518bytes，对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃这些数据帧。

由于以太网EthernetII最大的数据帧是1518Bytes这样，刨去以太网帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes那么剩下承载上层协议的地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为MTU。

以太网数据包（packet）由于环境限制，最大值是固定的，最初协议是1518字节，后来新协议是1522字节。但是MTU 仍是 1500Bytes。

为了允许一些使用以太II版本的数据报和一些使用802.3封装的最初版本的数据包能够在同一个以太网段使用，以太类型值必须大于等于1536(0x0600)。这个值比802.3数据包的最大长度1500byte (0x05DC)要更大。因此如果这个字段的值大于等于1536，则这个帧是以太II帧，而那个字段是类型字段。否则(小于1500而大于46字节)，他是一个IEEE 802.3帧，而那个字段是长度字段。1500～1536(不包含)的数值未定义。因为网络环境 MTU选择是1500【即以太网帧最大负载是1500字节】，所以我们上网用的以太网帧应该是 802.3帧。

来自维基百科

802.3 以太网帧结构
前导码	帧开始符	MAC 目标地址	MAC 源地址	802.1Q 标签 (可选)	以太类型	负载	冗余校验	帧间距
10101010 7个octet	10101011 1个octet	6 octets	6 octets	(4 octets)	2 octets	46–1500 octets	4 octets	12 octets
		64–1522 octets
72–1530 octets
84–1542 octets

IP 数据包在以太网数据包的负载里面，它也有自己的头信息，最少需要20字节，所以 IP 数据包的负载最多为1480字节。

（图片说明：IP 数据包在以太网数据包里面，TCP 报文段在 IP 数据包里面。）

TCP 报文段在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 报文段的最大负载是 1480 – 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。

因此，一条1500字节的信息需要两个 TCP报文段。HTTP/2 协议的一大改进，就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 报文段里面，而不是分成多个，这样就提高了速度。

（图片说明：以太网数据帧的负载是1500字节，TCP 报文段的负载在1400字节左右。）

三、TCP报文段的格式

图释:

抓包过后才发现，ip数据包首部没有添加可选项，就直接装载 tcp 数据了。

各个段位说明:

源端口和目的端口:　　各占 2 字节.端口是传输层与应用层的服务接口.传输层的复用和分用功能都要通过端口才能实现
序号:　　占 4 字节。用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
确认号:　　占 4 字节，期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
数据偏移/首部长度:　　占 4 位，指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。“数据偏移”的单位是 32 位字(以 4 字节为计算单位)
保留:　　占 6 位,保留为今后使用,但目前应置为 0
紧急URG:　　当 URG=1 时,表明紧急指针字段有效.它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)
确认ACK:　　只有当 ACK=1 时确认号字段才有效。当 ACK=0 时,确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
PSH(PuSH):　　接收 TCP 收到 PSH = 1 的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后再向上交付
RST (ReSeT):　　当 RST=1 时,表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因）,必须释放连接,然后再重新建立运输连接
同步 SYN:　　在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN:　　用来释放一个连接。FIN=1 表明此报文段的发送端的数据已发送完毕,并要求释放运输连接
窗口： 窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
检验和:　　占 2 字节.检验和字段检验的范围包括首部和数据这两部分.在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部
紧急指针:　　占 16 位,指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）
选项:　　长度可变.TCP 最初只规定了一种选项,即最大报文段长度 MSS.MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节.” [MSS(Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度.数据字段加上 TCP 首部才等于整个的 TCP 报文段]
填充:　　这是为了使整个首部长度是 4 字节的整数倍
其他选项:
- 窗口扩大:　　占 3 字节,其中有一个字节表示移位值 S.新的窗口值等于TCP 首部中的窗口位数增大到(16 + S),相当于把窗口值向左移动 S 位后获得实际的窗口大小
- 时间戳:　　占10 字节,其中最主要的字段时间戳值字段(4字节)和时间戳回送回答字段(4字节)
- 选择确认:　　接收方收到了和前面的字节流不连续的两2字节.如果这些字节的序号都在接收窗口之内,那么接收方就先收下这些数据,但要把这些信息准确地告诉发送方,使发送方不要再重复发送这些已收到的数据

四、TCP报文段特点

数据单位

TCP 传送的数据单位协议是 TCP 报文段(segment)

特点

TCP 是面向连接的传输层协议
每一条 TCP 连接只能有两个端点(endpoint),每一条 TCP 连接只能是点对点的（一对一）
TCP 提供可靠交付的服务
TCP 提供全双工通信
面向字节流

注意

TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的
TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP 发送的报文长度是应用进程给出的)
TCP 可把太长的数据块划分短一些再传送.TCP 也可等待积累有足够多的字节后再构成报文段发送出去
每一条 TCP 连接有两个端点
TCP 连接的端点不是主机,不是主机的IP 地址,不是应用进程,也不是传输层的协议端口.TCP 连接的端点叫做套接字(socket)或插口

五、TCP报文段的编号（SEQ）

一个报文段1400字节，那么一次性发送大量数据，就必须分成多个报文段（segment）。比如，一个 10MB 的文件，需要发送7100多个包。

发送的时候，TCP 协议为每个报文段编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢分段，也可以知道丢失的是哪一个报文段。

第一个报文段的编号是一个随机数。为了便于理解，这里就把它称为1号报文段。假定这个报文段的负载长度是100字节，那么可以推算出下一个报文段的编号应该是101。这就是说，每个报文段都可以得到两个编号：自身的编号，以及下一个报文段的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。

（图片说明：当前分段的编号是45943，下一个数据分段的编号是46183，由此可知，这个分段的负载是240字节。）

六、TCP 报文段的组装

收到 TCP 报文段以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 报文段。

对于应用程序来说，不用关心数据通信的细节。除非线路异常，收到的总是完整的数据。应用程序需要的数据放在 TCP 报文段里面，有自己的格式（比如 HTTP 协议）。

TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 报文段，将它们按照顺序组装好，一个分段都不少。

操作系统不会去处理 TCP 报文段里面的数据。一旦组装好 TCP 报文段，就把它们转交给应用程序。TCP 报文段里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。

（图片说明：系统根据 TCP 报文段里面的端口，将组装好的数据转交给相应的应用程序。上图中，21端口是 FTP 服务器，25端口是 SMTP 服务，80端口是 Web 服务器。）

应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。

七、建立连接和断开连接过程

报文段的发送时机

TCP 维持一个变量,它等于最大报文段长度 MSS.只要缓存中存放的数据达到 MSS 字节时,就组装成一个 TCP 报文段发送出去
由发送方的应用进程指明要求发送报文段,即 TCP 支持的推送(push)操作
发送方的一个计时器期限到了,这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去

发送TCP请求客户端

三次连接四次挥手

三个阶段:

连接建立:
- 图释:

- 步骤:
  - A 的 TCP 向 B 发出连接请求报文段,其首部中的同步位 SYN = 1,并选择序号 seq = x,表明传送数据时的第一个数据字节的序号是 x
  - B 的 TCP 收到连接请求报文段后,如同意,则发回确认(B 在确认报文段中应使 SYN = 1,使 ACK = 1,其确认号ack = x﹢1,自己选择的序号 seq = y)
  - A 收到此报文段后向 B 给出确认,其 ACK = 1,确认号 ack = y﹢1(A 的 TCP 通知上层应用进程,连接已经建立,B 的 TCP 收到主机 A 的确认后,也通知其上层应用进程：TCP 连接已经建立)
数据传送
连接释放:
- 图释:

- 步骤:
  - 数据传输结束后,通信的双方都可释放连接.现在 A 的应用进程先向其 TCP 发出连接释放报文段,并停止再发送数据,主动关闭 TCP 连接(A 把连接释放报文段首部的 FIN = 1,其序号seq = u,等待 B 的确认)
  - B 发出确认,确认号 ack = u＋1,而这个报文段自己的序号 seq = v(TCP 服务器进程通知高层应用进程.从 A 到 B 这个方向的连接就释放了,TCP 连接处于半关闭状态.B 若发送数据,A 仍要接收)
  - 若 B 已经没有要向 A 发送的数据,其应用进程就通知 TCP 释放连接
  - A 收到连接释放报文段后,必须发出确认,在确认报文段中 ACK = 1,确认号 ack=w﹢1,自己的序号 seq = u + 1
- 注意:

TCP 连接必须经过时间 2MSL 后才真正释放掉(2MSL 的时间的用意 — 为了保证 A 发送的最后一个 ACK 报文段能够到达 B.防止 “已失效的连接请求报文段”出现在本连接中.A 在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段,都从网络中消失.这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段)

- 发现丢失确认时候的处理:

三个问题:

要使每一方能够确知对方的存在
要允许双方协商一些参数(如最大报文段长度,最大窗口大小,服务质量等)
能够对运输实体资源(如缓存大小,连接表中的项目等)进行分配

四次挥手：

A：我这边传完了，你那边收接收完了没？B：我这边接收完了。A就不传输信息了。

B：我这边传完了，你那边收接收完了没？A：我这边接收完了。B就不传输信息了。

七、滑动窗口（发送窗口-接收窗口-拥塞窗口）

滑动窗口

图释:

特点:

以字节为单位的滑动窗口
A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）

要求:

TCP 标准没有规定对不按序到达的数据应如何处理.通常是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程
TCP 要求接收方必须有累积确认的功能,这样可以减小传输开销

具体实现:

七、拥塞避免

服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。

最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？

1、慢开始算法

TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢报文段的情况，调整速率：如果不丢报文段，就加快发送速度；如果丢报文段，就降低发送速度。

Linux 内核里面设定了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个报文段，即”发送窗口”的大小为10。然后停下来，等待接收方的确认，再继续发送。

默认情况下，接收方每收到两个 TCP 报文段，就要发送一个确认消息。”确认”的英语是 acknowledgement，所以这个确认消息就简称 ACK。

ACK 携带两个信息。

期待要收到下一个数据包的编号

接收方的接收窗口的剩余容量

发送方有了这两个信息，再加上自己已经发出的报文段的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为”发送窗口”，这个窗口的大小是可变的。

（图片说明：每个 ACK 都带有下一个报文段的编号，以及接收窗口的剩余容量。双方都会发送 ACK。）

注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个报文段里面发送。

（图片说明：上图一共4次通信。第一次通信，A 主机发给B 主机的报文段编号是1，长度是100字节，因此第二次通信 B 主机的 ACK 编号是 1 + 100 = 101，第三次通信 A 主机的报文段编号也是 101。同理，第二次通信 B 主机发给 A 主机的报文段编号是1，长度是200字节，因此第三次通信 A 主机的 ACK 是201，第四次通信 B 主机的报文段编号也是201。）

即使对于带宽很大、线路很好的连接，TCP 也总是从10个报文段开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。

慢开始算法:

在主机刚刚开始发送报文段时可先设置拥塞窗口 cwnd = 1,即设置为一个最大报文段 MSS 的数值
在每收到一个对新的报文段的确认后,将拥塞窗口加 1,即增加一个 MSS 的数值
使用慢开始算法后,每经过一个传输轮次(往返时间 RTT),拥塞窗口 cwnd 就加倍

2、拥塞避免算法:

拥塞窗口 cwnd 缓慢地增大,即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1,使拥塞窗口 cwnd 按线性规律缓慢增长

3、慢开始门限 ssthresh 的用法:

当 cwnd < ssthresh 时,使用慢开始算法
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法
当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法

4、网络出现拥塞时（其根据就是没有按时收到确认）:

就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半(但不能小于2)
然后把拥塞窗口 cwnd 重新设置为 1.执行慢开始算法

八、拥塞处理

拥塞窗口:

含义:

拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化.发送方让自己的发送窗口等于拥塞窗口.如再考虑到接收方的接收能力,则发送窗口还可能小于拥塞窗口

发送方控制拥塞窗口的原则:

只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去.但只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数

乘法减小:

是指不论在慢开始阶段还是拥塞避免阶段,只要出现一次超时(即出现一次网络拥塞),就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5

加法增大:

是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个往返时间),就把拥塞窗口 cwnd增加一个 MSS 大小,使拥塞窗口缓慢增大,以防止网络过早出现拥塞

快重传:

每一个TCP报文段都带有下一个报文段的编号。如果下一个报文段没有收到，那么 ACK 的编号就不会发生变化。

举例来说，现在收到了4号报文段，但是没有收到5号报文段。ACK 就会记录，期待收到5号报文段。过了一段时间，5号报文段收到了，那么下一轮 ACK 会更新编号。如果5号报文段还是没收到，但是收到了6号报文段或7号报文段，那么 ACK 里面的编号不会变化，总是显示5号报文段。这会导致大量重复内容的 ACK。

如果发送方发现收到三个连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢失报文段，即5号报文段遗失了，从而再次发送这个报文段。通过这种机制，TCP 保证了不会有报文段丢失。

（图片说明：Host B 没有收到100号报文段，会连续发出相同的 ACK，触发 Host A 重发100号报文段。）

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认.这样做可以让发送方及早知道有报文段没有到达接收方,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段

快恢复:

当发送端收到连续三个重复的确认时,就执行“乘法减小”算法,把慢开始门限 ssthresh 减半.但接下去不执行慢开始算法

发送窗口的上限值:

发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个,即应按以下公式确定：
发送窗口的上限值 Min [rwnd, cwnd]

- 当 rwnd < cwnd 时,是接收方的接收能力限制发送窗口的最大值
- 当 cwnd < rwnd 时,则是网络的拥塞限制发送窗口的最大值

九、报文段的遗失处理-自动重传

TCP 协议可以保证数据通信的完整性，这是怎么做到的？

自动重传请求ARQ

定义:

可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)

累积确认:

定义:　　接收方一般采用累积确认的方式.即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示：到这个分组为止的所有分组都已正确收到了
优点:　　容易实现,即使确认丢失也不必重传
缺点:　　不能向发送方反映出接收方已经正确收到的所有分组的信息

Go-back-N(回退N):

如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了.这时接收方只能对前两个分组发出确认.发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次

具体实现

说明:

TCP 连接的每一端都必须设有两个窗口一个发送窗口和一个接收窗口
TCP 可靠传输机制用字节的序号进行控制.TCP 所有的确认都是基于序号而不是基于报文段
TCP 两端的四个窗口经常处于动态变化之中
TCP连接的往返时间 RTT 也不是固定不变的.需要使用特定的算法估算较为合理的重传时间

图释:

确认丢失和确认迟到

超时重传时间选择

具体实现:

TCP 每发送一个报文段,就对这个报文段设置一次计时器.只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段

加权平均往返时间:

做法:

TCP 保留了 RTT 的一个加权平均往返时间 RTTS（这又称为平滑的往返时间）,第一次测量到 RTT 样本时,RTTS 值就取为所测量到的 RTT 样本值.以后每测量到一个新的 RTT 样本,就按下式重新计算一次 RTTS：

公式:

新的 RTTS = ( 1 – α)×(旧的 RTTS)＋α(新的 RTT 样本)

说明:

式中,0 ≤ α＜ 1.若α很接近于零,表示 RTT 值更新较慢若选择 α 接近于1,则表示 RTT 值更新较快
RFC 2988 推荐的 α 值为 1/8,即 0.125

超时重传时间RTO:

RTO 应略大于上面得出的加权平均往返时间 RTTS.
RFC 2988 建议使用下式计算 RTO：

RTO=RTTS + 4×RTTD

RTTD 是 RTT 的偏差的加权平均值
RFC 2988 建议这样计算 RTTD.第一次测量时,RTTD 值取为测量到的 RTT 样本值的一半.在以后的测量中,则使用下式计算加权平均的 RTTD：

新的 RTTD = (1-β)×(旧的RTTD)+β×|RTTS﹣新的 RTT 样本|

β是个小于 1 的系数,其推荐值是 1/4,即 0.25
在计算平均往返时间 RTT 时,只要报文段重传了,就不采用其往返时间样本

修正的Karn算法:

报文段每重传一次,就把 RTO 增大一些：

新的 RTO= γ×(旧的 RTO)

系数γ 的典型值是 2
当不再发生报文段的重传时,才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值

持续计时器

TCP 为每一个连接设有一个持续计时器
只要 TCP 连接的一方收到对方的零窗口通知,就启动持续计时器
若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带 1 字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值
若窗口仍然是零,则收到这个报文段的一方就重新设置持续计时器
若窗口不是零,则死锁的僵局就可以打破了

九、缓存控制

发送缓存

发送缓存用来暂时存放：

发送应用程序传送给发送方 TCP 准备发送的数据
TCP 已发送出但尚未收到确认的数据

图释:

接收缓存

接收缓存用来暂时存放：

按序到达的、但尚未被接收应用程序读取的数据；
不按序到达的数据

图释:

参考：

http://www.cnblogs.com/kzang/articles/2582957.html

http://www.ruanyifeng.com/blog/2017/06/tcp-protocol.html

https://blog.csdn.net/u014222687/article/details/55002177

0 0 votes

Article Rating