传输层
传输层协议主要是为不同主机上的不同进程间提供了逻辑通信的功能。传输层只工作在端对端系统中。
传输层需要 2 种不同传输协议：面向连接 TCP 和 非连接 UDP
主要协议有：TCP 和 UDP 。
实现的主要功能：保证传输的可靠性，并且实现一些差错恢复机制。
传输层的端口：实际上是用来标识应用层的进程
IP 层用的是无连接的协议，代表性的面向连接的协议是电话(两个电话通信有电话线)，IP 协议不存在一条固定的线路，是通过路由的自由选择实现的
目录
多路复用与多路分解
将传输层报文段中的数据 传送 到正确的 Socket 的工作被称为多路分解。
在源主机上从不同的 Socket 中收集数据，封装头信息生成报文段后，将报文段传递到网络层，这个过程被称为多路复用。
无连接的多路复用和多路分解指的是 UDP Socket 的分配过程，一个 UDP Socket 由一个二元组来标识，这个二元组包含了一个目的地址和一个目的端口号。
因此不同源地址和端口号的 UDP 报文段到达主机后，如果它们拥有相同的目的地址和目的端口号，那么不同的报文段将会转交到同一个 UDP Socket 中。
面向连接的多路复用和多路分解指的是 TCP Socket 的分配过程，一个 TCP Socket 由一个四元组来标识，这个四元组包含了源 IP 地址、源端口号、目的地址和目的端口号。
因此，一个 TCP 报文段从网络中到达一台主机上时，该主机使用全部 4 个值来将报文段定向到相应的 Socket。
Socket（插口，套接字）
TCP 使用连接（而不仅仅是“端口”）作为基本的抽象单位，同时将 TCP 连接的断点称为 Socket
Socket 和 端口，IP 地址的关系：
Socket = IP 地址:端口 （IP 和端口组合，IP 标识主机，端口标识进程）
TCP 与 UDP
两个同等传输实体在通信时传送的数据单位叫传输协议数据单元(TPDU,Transport Protocol Data Unit)
UDP 传输的数据单位协议是 UDP 报文
TCP 传输的数据单位协议是 TCP 报文段
UDP 协议
UDP 是一种无连接的，不可靠的传输层协议。在传送数据之前不需要建立连接，对方的传输层在收到 UDP 报文后，也不需要给出任何确认。
它只提供了传输层需要实现的最低限度的功能，除了复用/分解功能和少量的差错检测外，它几乎没有对 IP 增加其他的东西。
UDP 协议适用于对 实时性要求高 的应用场景，因为它无连接，不需要反馈，所以简单，快捷
特点(UDP)：
1. 无连接
- 使用 UDP 时，在发送报文段之前，通信双方没有握手的过程，因此 UDP 被称为是无连接的传输层协议。因为没有握手过程，相对于 TCP 来说，没有建立连接的时间消耗。
2. 不可靠
- UDP 提供尽力而为的交付服务，也就是说 UDP 协议不保证数据的可靠交付。
3. 发送速率无限制
- UDP 没有拥塞控制和流量控制的机制，所以 UDP 报文段的发送速率没有限制。
4. 通信方式多样
- 因为一个 UDP 套接字只使用目的地址和目的端口来标识，所以 UDP 可以支持一对一、一对多、多对一和多对多的交互通信（收发不能同时，收了才能发，发了才能收）。
5. 小
- UDP 头部小，只有 8 个字节。
UDP 报文段结构
UDP 报文段由头部和应用数据组成。报文段头部包含四个字段，分别是源端口号、目的端口号、长度和检验和，每个字段的长度为两个字节（头部共 8 字节）。
长度字段指的是整个报文段的长度，包含了首部和应用数据的大小。
校验和是 UDP 提供的一种差错校验机制。
虽然提供了差错校验的机制，但是 UDP 对于差错的恢复无能为力。
TCP 协议
TCP 协议是面向连接的，提供可靠数据传输服务的传输层协议。
特点(TCP)：
1. 面向连接
- TCP 协议是面向连接的，在通信双方进行通信前，需要通过三次握手建立连接。它需要在端系统中维护双方连接的状态信息。
2. 可靠
- TCP 协议通过序列号、确认号、定时重传、检验和等机制，来提供可靠的数据传输服务。
3. 一对一
- TCP 协议提供的是点对点的服务，即它是在单个发送方和单个接收方之间的连接。
4. 全双工服务
- TCP 协议提供的是全双工的服务，也就是说连接的双方的能够向对方发送和接收数据。
5. 拥塞控制机制
- TCP 提供了拥塞控制机制，在网络拥塞的时候会控制发送数据的速率，有助于减少数据包的丢失和减轻网络中的拥塞程度。
6. 流量控制机制
- TCP 提供了流量控制机制，保证了通信双方的发送和接收速率相同。如果接收方可接收的缓存很小时，发送方会降低发送速率，避免因为缓存填满而造成的数据包的丢失。
TCP 报文段结构
TCP 报文段由头部和数据组成，它的头部一般为 20 个字节。
源端口和目的端口号用于报文段的多路复用和分解。
32 比特的序列号和 32 比特的确认号，用于实现数据的可靠传输服务。
16 比特的接收窗口字段用于实现流量控制，该字段表示接收方愿意接收的字节的数量。
4 比特的头部长度字段，该字段指示了以 32 比特的字为单位的 TCP 头部的长度。
6 比特的标志字段，ACK 字段用于指示确认序列号的值是有效的。
RST、SYN 和 FIN 比特用于连接建立和拆除。
设置 PSH 字段指示接收方应该立即将数据交给上层。
URG 字段用来指示报文段里存在紧急的数据。
校验和提供了对数据的差错检测。
TCP 三次握手
序列号 seq：占 4 个字节，用来标记数据段的顺序。
确认号 ack：占 4 个字节，期待收到对方下一个报文段的第一个数据字节的序号。
确认 ACK：占 1 位，仅当 ACK=1 时，确认号字段才有效。ACK=0 时，确认号无效
同步 SYN：连接建立时用于同步序号。当 SYN=1，ACK=0 时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得 SYN=1，ACK=1。因此，SYN=1 表示这是一个连接请求，或连接接受报文。SYN 这个标志位只有在 TCP 建产连接时才会被置 1，握手完成后 SYN 标志位被置 0。
终止 FIN：用来释放一个连接。FIN=1 表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接
第一次握手：
- 客户端向服务端发送一个 SYN(seq=x) 连接请求报文，并进入 SYN_SENT 状态 ，等待服务器确认。
SYN=1，序列号 seq字段最开始是一个任选的随机数 x，它代表客户端数据的初始序列号。
第一次握手后，服务端知道了 自己可以与客户端连接成功，但此时客户端还不知道
第二次握手：
-
服务端收到 SYN 包，首先会为该连接分配 TCP 缓存和变量，然后返回 ACK(ack=x+1)确认报文，同时自己也发送一个 SY(syn=y)，即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态。
SYN=1,ACK=1，序列号字段是服务端产生的一个任选的随机数 y，它代表服务端数据的初始序列号。确认号字段为客户端发送的序列号+1。
第二次握手后，客户端收到了服务端的反馈，确定了自己可以于服务端连接成功
第三次握手
-
客户端收到服务器的 SYN+ACK 包，也会为这次 TCP 连接分配缓存和变量，然后向服务器发送确认包ACK(ack=y+1)(seq=x+1)，此包发送完毕，客户端和服务器进入ESTABLISHED（TCP 连接成功）状态，完成三次握手。
ACK=1，序列号字段为客户端 x+1，确认号字段为服务端发送的序列号 y+1
第三次握手，防止失效的请求报文段被服务端接收
TCP 三次握手的建立连接的过程就是相互确认初始序列号的过程，告诉对方，什么样序列号的报文段能够被正确接收。
第三次握手的作用是客户端对服务端的初始序列号的确认。如果只使用两次握手，那么服务端就没有办法知道自己的序列号是否已被确认。同时这样也是为了防止失效的请求报文段被服务端接收，而出现错误的情况。
比如：
客户端发出去的第一个连接请求由于某些原因在网络节点中滞留了导致延迟，
直到连接释放的某个时间点才到达服务端，这是一个早已失效的报文，
但此时服务端仍然认为这是客户端的 第一次握手，于是服务端回应了客户端，第二次握手。
TCP 四次挥手
因为 TCP 连接是全双工的，也就是说通信的双方都可以向对方发送和接收消息，所以断开连接需要双方的确认。
第一次挥手
- 客户端认为没有数据要再发送给服务端，它就向服务端发送一个 FIN 报文段，申请断开客户端到服务端的连接。
发送后客户端进入 FIN_WAIT_1 状态。
第二次挥手
- 服务端收到后，向客户端发送一个确认报文段ACK，表示已经接收到了客户端释放连接的请求，以后不再接收客户端发送过来的数据。但是因为连接是全双工的，所以此时，服务端还可以向客户端发送数据。
服务端进入 CLOSE_WAIT 状态。
客户端收到确认后，进入 FIN_WAIT_2 状态。
第三次挥手
- 服务端发送完所有数据后，向客户端发送 FIN ACK 报文段，申请断开服务端到客户端的连接。
发送后进入 LAST_ACK 状态。
第四次挥手
- 客户端接收到 FIN 请求后，向服务端发送一个确认报文段 ACK ，并进入 TIME_WAIT 阶段 。
服务端收到客户端的确认报文段后就立即进入 CLOSED 状态。
客户端 TIME_WAIT 阶段 会持续一段时间，这个时间为报文段在网络中的最大生存时间，如果该时间内服务端没有重发请求的话，客户端就进入 CLOSED 状态。如果收到服务端的重发请求就重新发送确认报文。
这样全双工的连接就被释放了。
TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的，所以需要双方分别释放到对方的连接，单独一方的连接释放，只代表不能再向对方发送数据，连接处于的是半释放的状态。
最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务端的确认报文段丢失或者出错，从而导致服务端不能正常关闭。
状态转化图
ARP 协议
ARQ 协议指的是自动重传请求，它通过超时和重传来保证数据的可靠交付，它是 TCP 协议实现可靠数据传输的一个很重要的机制。
它分为停止等待 ARQ 协议和连续 ARQ 协议。
一、停止等待 ARQ 协议
-
停止等待 ARQ 协议的基本原理是，对于发送方来说发送方每发送一个分组，就为这个分组设置一个定时器。当确认回答返回了，则清除定时器，发送下一个分组。如果在规定的时间内没有收到确认回答，则重新发送上一个分组。
-
对于接受方来说，每次接受到一个分组，就返回对这个分组的肯定应答，当收到重复的分组时，就直接丢弃，并重新返回 确认报文。当收到分组损坏的情况的时候，直接丢弃。
使用停止等待 ARQ 协议的缺点是每次发送分组必须等到分组确认后才能发送下一个分组，这样会造成信道的利用率过低。
举例（发送方问题）
如果 A 发送的过程中出现差错，B 在接收 M1 时检测出了差错，就丢弃 M1，其他什么都不做（也不会通知 A 收到有差错的分组）。又或者 A 传送的过程中分组丢失了，以上这两种情况下，B 不会发送任何信息。
如果发生以上的情况，A 只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，所以它会重传刚刚的发送过的分组，也就是所谓的超时重传。
超时重传的原理：发送方发送完一个分组后，就会设置一个超时计时器，如果超时计时器到期之前没有收到接收方发来的确认信息，则会重发刚发送过的分组；如果收到确认信息，则撤销该超时计时器。
举例（接收方问题）
如果 A 发送了 M1 分组，到达 B，B 发送了 M1 确认信息，但由于网络原因，该确认信息丢失。那么这个时候，A 在超时重传时间内，没有收到 B 的确认信息，而且它并不知道是自己的分组有差错、丢失，还是 B 发生的确认丢失了。因此，A 会在超时重传过后，重传 M1 分组。
接收方 B 会采取这两个行动：
① B 会丢弃 M1 分组，不向上层交付。（B 之前已经收到过 M1 分组了）
② 向 A 发送确认（因为 A 重发了，肯定重传时间内没有收到确认信息）
二、连续 ARQ 协议
连续 ARQ 协议是为了解决停止等待 ARQ 协议对于信道的利用率过低的问题。它通过连续发送一组分组，然后再等待对分组的确认回答，对于如何处理分组中可能出现的差错恢复情况，一般可以使用滑动窗口协议和选择重传协议来实现。
- 滑动窗口协议
在在发送方和接收方之间各自维持一个滑动窗口，发送发是发送窗口，接收方是接收窗口，而且这个窗口是随着时间变化可以向前滑动的。它允许发送方发送多个分组而不需等待确认。TCP 的滑动窗口是以字节为单位的。
连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果收到的是第 5 个分组的确认，那么移动到第六 6 个分组。
接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。
累积确认
优点是容易实现，即使确认丢失也不必重传。
缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。
比如发送方发送了前 5 个分组，而中间的第 3 个分组丢失了，这时候接收方只能对前 2 个发出确认。而不知道后面 3 个分组的下落，因此只能把后面的 3 个分组都重传一次，这种机制叫 Go-back-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。
- 选择重传协议
接收端总会缓存所有收到的帧，当某个帧出现错误时，只会要求重传这一个帧，只有当某个序号后的所有帧都正确收到后，才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。
TCP 的可靠运输机制
TCP 的可靠运输机制是基于连续 ARQ 协议和滑动窗口协议的。
已经发送并确认 |============= 发送窗口 ===========| 缓存中还不允许发送的 |
============= |已经发送但未确认 | 允许发送但还未发送| ===================|
TCP 协议在发送方维持了一个发送窗口，发送窗口以前的报文段是已经发送并确认了的报文段，发送窗口中包含了已经发送但未确认的报文段和允许发送但还未发送的报文段，发送窗口以后的报文段是缓存中还不允许发送的报文段。当发送方向接收方发送报文时，会依次发送窗口内的所有报文段，并且设置一个定时器，这个定时器可以理解为是最早发送但未收到确认的报文段。
不大理解
TCP 协议的可靠传输机制更像是窗口滑动协议和选择重传协议的一个混合体。
TCP 的流量控制机制
TCP 提供了流量控制的服务，这个服务的主要目的是控制发送方的发送速率，保证接收方来得及接收。因为一旦发送的速率大于接收方所能接收的速率，就会造成报文段的丢失。接收方主要是通过接收窗口来告诉发送方自己所能接收的大小，发送方根据接收方的接收窗口的大小来调整发送窗口的大小，以此来达到控制发送速率的目的。
TCP 的拥塞控制机制
TCP 的拥塞控制主要是根据网络中的拥塞情况来控制发送方数据的发送速率，如果网络处于拥塞的状态，发送方就减小发送的速率，这样一方面是为了避免继续增加网络中的拥塞程度，另一方面也是为了避免网络拥塞可能造成的报文段丢失。
TCP 的拥塞控制主要使用了四个机制，分别是慢启动、拥塞避免、快速重传和快速恢复。
慢启动的基本思想是，因为在发送方刚开始发送数据的时候，并不知道网络中的拥塞程度，所以先以较低的速率发送，进行试探，每次收到一个确认报文，就将发送窗口的长度加一，这样每个 RTT 时间后，发送窗口的长度就会加倍。当发送窗口的大小达到一个阈值的时候就进入拥塞避免算法。
拥塞避免算法是为了避免可能发生的拥塞，将发送窗口的大小由每过一个 RTT 增长一倍，变为每过一个 RTT ，长度只加一。这样将窗口的增长速率由指数增长，变为加法线性增长。
快速重传指的是，当发送方收到三个冗余的确认应答时，因为 TCP 使用的是累计确认的机制，所以很有可能是发生了报文段的丢失，因此采用立即重传的机制，在定时器结束前发送所有已发送但还未接收到确认应答的报文段。
快速恢复是对快速重传的后续处理，因为网络中可能已经出现了拥塞情况，所以会将慢启动的阀值减小为原来的一半，然后将拥塞窗口的值置为减半后的阀值，然后开始执行拥塞避免算法，使得拥塞窗口缓慢地加性增大。简单来理解就是，乘性减，加性增。
TCP 认为网络拥塞的主要依据是报文段的重传次数，它会根据网络中的拥塞程度，通过调整慢启动的阀值，然后交替使用上面四种机制来达到拥塞控制的目的。