1-传输层
- 1.1 UDP 和 TCP 的特点
- - 1.1.1 UDP用户数据报格式
  - 1.1.2 TCP首部格式
  - - 1.1.2.1 常用端口号
- 1.2 TCP的三次握手
- - 1.2.1 三次握手的原因
- 1.3 TCP四次挥手
- - 1.3.1 四次挥手的原因
  - 1.3.2 TIME_WAIT为什么是2MSL
- 1.4 TCP的可靠传输有效机制
- - 1.4.1 TCP可靠传输-超时重传
  - 1.4.2 TCP流量控制
  - 1.4.3 TCP拥塞控制
  - - 1.4.3.1 怎么进行拥塞控制
    - - 1.慢开始
      - 2.拥塞避免
      - 3.快重传
      - 4.快恢复
  - 1.4.4确认应答机制
  - 1.4.5 延迟应答
- 1.5TCP和UDP的区别
- 1.6 基于TCP和UDP的应用层协议
- - 1.6.1 TCP
  - 1.6.2 UDP
- 1.8 用UDP实现可靠传输

1-传输层

网络层只把分组发送到目的主机，但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信，传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

1.1 UDP 和 TCP 的特点

用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
传输控制协议 TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。

1.1.1 UDP用户数据报格式

1.1.2 TCP首部格式

1.1.2.1 常用端口号

0-1023：知名端口号，HTTP\FTP\SSH等应用层端口都是固定的
1024-65535：客户端程序端口号，操作系统动态分配的端口号
知名端口号：

ssh服务器–22

ftp服务器–21

teInet服务器–23

http服务器—80

https服务器–443

1.2 TCP的三次握手

一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
服务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。
客户端收到服务端发送的 SYN 和 ACK 之后，发送 SYN 的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。

1.2.1 三次握手的原因

·1第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

2.保证双方的序号是同步的，这是TCP可靠传输的重要原因

每一个SYN都要有对应的ACK，确保双方都具有发送和接收数据的功能

3.防止资源浪费

1.3 TCP四次挥手

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

1.3.1 四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

1.3.2 TIME_WAIT为什么是2MSL

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：2MSL怎么来的
(1)确保后一个确认报文ACK能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文， A 等待一段时间就是为了处理这种情况的发生。

(2)等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的
而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：
网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

1.4 TCP的可靠传输有效机制

是什么？为什么？怎么做

超时重传、滑动窗口、流量控制、拥塞控制

（1）确认和重传机制：建立连接、发送包时的确认，运输过程中校验失败、丢包或延时发送端重传

（2）数据排序：把数据分成很多包，按顺序进行传输

（3）流量控制：滑动窗口和计时器

（4）拥塞控制：慢启动、拥塞避免、快速重传、快速恢复

1.4.1 TCP可靠传输-超时重传

如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

1.4.2 TCP流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收，作用于接收方，防止分组丢失的。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

1.4.3 TCP拥塞控制

作用于网络，防止过多的数据注入到网络中，避免出现网络负载过大的情况。
拥塞：对网络中某一资源的需求超过了该资源所能提供的可用部分，影响到网络性能

1.4.3.1 怎么进行拥塞控制

拥塞窗口：

发送数据端使用的窗口大小，拥塞窗口不代表缓存，拥塞窗口指某一源端数据流在一个RTT内可以最多发送的数据包数。

1.慢开始

当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能因为不清楚当前网络的负荷情况而引起网络阻塞。所以，最好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚发送报文段时，先把拥塞窗口cwnd设置为 1 个最大报文段MSS的数值。而在每收到一个新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值（1个确认报文对应2个MSS，即：呈指数增长）。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。

注意：慢开始当中的“慢”并不是指cwnd的增长速率慢，而是在TCP开始发送报文段时先设置cwnd = 1,使得发送方在开始时只发送一个报文段。

2.拥塞避免

让拥塞窗口cwnd缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd + 1，而不是加倍，即：呈线性增长。这样拥塞窗口cwnd按线性规律缓慢的增长，比慢开始算法的拥塞窗口增长速率缓慢的多。

3.快重传

所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。

要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认；
即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。