网络学习---网络分层---传输层

传输层（Transport）

这章很重要！网络相关的问题是必考知识点

传输层有2个协议
TCP（Transport Control Protocol），传输控制协议
UDP（User Datagram Protocol），用户数据报协议

---

UDP

• UDP是无链接的，减少了建立和释放链接的开销
• UDP尽最大能力交付，不保证可靠交付
  因此，不需要维护一些复杂的参数，首部只有8个字节
  占16位，首部的长度 + 数据的长度
• UDP检验和
  检验和的计算内容：伪首部 + 首部 + 数据

伪首部：仅在计算检验和时起作用，并不会传递给网络层

端口（Port）

• UDP首部中端口是占用2个字节
  可以推测出，端口号的取值范围为：0-65535

• 客户端的源端口是临时开启的随机端口

• 防火墙可以设置开启\关闭某些端口来提高安全性

一般聊天、直播是使用UDP传输协议

---

TCP

TCP的也是由首部 + 数据 部分组成
其首部至少占20个字节

TCP - 数据格式

哇，TCP首部里面好多东西，都是做什么用的呢？
来，我们一起学习下！

• 数据偏移
  占4位
  乘以4，是位首部长度（Header Length）

该首部长度是20位的固定长度+可选部分等
其实，数据偏移，偏移出的位子用来放首部数据，岂不就是偏移量与首部对应上了

• 保留
  占6位，目前全是0
  保留位后面的占6位，里面每一个单词（称为标记位）占一位

传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度

• 检验和（Checksum）
  跟UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据

伪首部：占用12个字节，仅在计算检验和时起作用，并不会传递给网络层

TCP - 标志位（Flags）

• URG（Urgent）
  当URG = 1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

• ACK（Acknowledgment）
  当ACK = 1时，确认号字段才有效

• PUSH

• RST（Reset）
  当RST = 1时，表明连接中出现严重差错，必须释放连接，然后重新建立连接

• SYN（Synchronization）
  当SYN = 1、ACK = 0时，表明这是一个建立连接的请求
  若对方同意建立连接，则回复SYN = 1、ACK = 1

• FIN（Finish）
  当FIN = 1时，表明数据已经发送完毕，要求释放连接

TCP - 序号、确认号、窗口

• 序号（Sequence Number）
  占4字节
  在传输过程中，每一个字节都有一个编号
  在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号

• 确认号（Acknowledgment Number）
  占4字节
  在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号

• 窗口（Window）
  占2个字节
  这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（单位：字节）

---

问：为何TCP的首部要设计的这么复杂呢？

之所以TCP的首部设计这么复杂，是因为TCP有几个特点需要去保证，或者说是TCP的存在意义，为了保证这几个要点，因此，需要将TCP的首部设计成如图所示的样子，从而满足需求。
那么，TCP有哪些特点呢？

TCP的几个要点

1. 可靠传输
2. 流量控制
3. 拥塞控制

问：TCP是如何保证可靠传输的呢？

1.TCP可靠传输 - 停止等待ARQ协议

• ARQ（Automatic Repeat-reQuest），自动重传请求
  

上述确实安全，但有个问题，如果有1000个字节，分10次传输，每次都要确认是否超时重传，每次都要等待，假如：超时设置为1秒，那么，有可能总共需要判断10秒的超时重传。单次判断，有点浪费时间，有没有改进的办法呢？
当然是有的

TCP可靠传输 - 连续ARQ协议 + 滑动窗口协议

左边的还是老的ARQ协议
右边的使用连续ARQ协议 + 窗口协议，连续ARQ可以使每次发送的数据变多，窗口可以控制每次发送的大小

比如，在传输1、2、3、4、5的时候3丢失了
那么，原来的TCP会重传最后确认的分组后续的分组（意思是会重传3、4、5）
而原来已经发送的4、5也要重传，造成一定的性能缺陷

为了改进这种缺陷，TCP有SACK（Selective Acknowledgment，选择性确认）技术

TCP可靠传输 - SACK选择性确认

告诉发送方，哪些数据丢失，哪些数据已经收取到
使TCP只重新发送丢失的包（比如3），而不需要重复发送已接收到的包（4、5）

---

我们知道，滑动窗口其实是有一个缓存区的
如果缓存区已经满了，发送方还在不停的发送数据，那么，接收方会选择把收到的数据包丢掉，这样，就造成了浪费。

问：如何解决呢？

这就需要流量控制了

2. TCP流量控制

流量控制： 发送方的速率不要太快，让接收方来得及接收处理

具体做法是：

• 通过确认报文中窗口字段来控制发送方的发送速率
• 发送方的窗口大小，不能超过接收方的窗口大小
• 当发送方 收到 接收方的窗口大小为0时，发送方就会停止发送数据

3. TCP拥塞控制

假如链路的吞吐量是1000M/s
现在的数据达到了1300M/s
这样，就造成了拥塞

拥塞发生的话，有可能会出现丢包的现象，因此，要做好拥塞控制

• 拥塞控制
  防止过多的数据注入到网络中
  避免网络中的路由器 或 链路 过载

拥塞控制是一个全局性的过程

拥塞控制方法：

• 慢开始（slow start，慢启动）
• 拥塞避免（congestion avoidance）
• 快速重传（fast retransmit）
• 快速恢复（fast recovery）

---

TCP - 连接管理

连接管理分为：

• 建立连接
• 释放连接
  也就是传说中的：三次握手、四次挥手

具体实现步骤，我们看下Wireshark的抓包过程
首先，下载Wireshark
下载错误后，可能会遇到You don't have permission to capture on that device报错信息，可参考解决

然后，我们抓http://icp.chinaz.com/网址的包，通过过滤，可以找到建立连接过程：

该图上是两个传输层通过TCP协议建立连接的过程，正如红色框部分显示的那样：

1. 49600向80端口强求建立连接，发送SYN
2. 80端口接收到请求建立连接后，发送ACK确认收到其的请求建立连接，并回应SYN也请求建立连接
3. 49600接收到80发送的ACK和SYN后，再次给80段口发送SYN确认连接，确认收到的80的ACK
   此时，三次握手完成，建立连接就成功了。

画图可表示为：

需要注意的是，只有前两次握手SYN才是1，第三次握手SYN为0

从抓包数据可以看出，第三次握手，SYN确实是0

---

在传输数据的时候，第一次服务器给客户端发送了长度为361的数据
客户端确认收到361，ACK=362，告诉服务端下次请发送362开头的数据
服务端收到客户端说的，从362开始发送，然后Seq=362，发送数据长度为1440的数据

361 + 1440 + 1440 = 3241
因此，第57行，Ack = 3242
第59行，Seq = 3242

还是得自己手动操作一下，这样可以使得枯燥无味的知识点呈现出来，更加实体化、更容易理解

---

TCP-建立连接-3次握手🤝

• CLOSE: client处于关闭状态
• LISTEN: server处于监听状态，等待client连接
• SYN-RCVD(received)：表示server接收到了SYN报文，当接收到client的ACK报文后，它会进入ESTABLISHED状态
• SYN-SET：表示client已发送SYN报文，等待server的第2次握手
• ESTABLISHED（已建立的）：表示连接已经建立

前两次握手
SYN = 1
数据部分 = 0

第三次握手失败了，会怎样处理？
此时，server的状态已经是SYN-RVCD，若等不到client的ACK，server会重新发送SYN+ACK包
如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接

---

TCP-释放连接-4次挥手

各个状态：

• FIN-WAIT-1：表示想主动关闭连接
  向对方发送FIN报文后，此时进入FIN-WAIT-1状态
• CLOSE-WAIT：表示在等待关闭
  当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时自己则进入CLOSE-WAIT状态
  在此状态下，被动方需要看自己是否还有数据要发送给对方，如果没有，则发送FIN报文给对方
• FIN-WAIT-2: 只要被动方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
• CLOSING：一种比较罕见的例外状态
  如果主动方发送FIN报文后，并没有收到被动方发来的ACK确认报文，却收到了被动放的FIN报文，那么，主动方就会进入CLOSING状态，表示双方都正在关闭连接

你想分手，刚发过去：我们分手吧，却收到对方的信息：我们分手吧。你们俩真有缘分，分，直接进而CLOSING状态

• LAST-ACK：被动方发送FIN报文后，进入LAST-ACK状态，等待主动方的ACK报文
  当收到主动方的ACK后，则被动方会进入CLOSED

• TIME-WAIT：表示主动方收到了被动方的FIN报文，并主动方发送出了ACK报文，然后等2倍的MSL时间后，主动方就可以进入到CLOSED状态
  MSL(max segment lifetime，最大分段生存期)
  MSL是TCP报文在internet上的最长生存时间，建议是2分钟

• CLOSED：关闭状态

---

问：为什么释放连接需要4次挥手？

要了解为什么需要四次挥手，首先要了解4次挥手都起什么作用

TCP是全双工模式
第1次挥手：当主机1发出FIN报文段时
表示主机1告诉主机2，主机1已经没有数据要发送了，但，此时主机1还是可以接收来自主机2的数据

第2次挥手：当主机2返回ACK报文段时
表示主机2已经知道主机1没有数据发送了，但是，主机2还是可以发送数据到主机1

第3次挥手：当主机2也发送了FIN报文段时
表示主机2告诉主机1，主机2已经没有数据要发送了

第4次挥手：当主机1返回ACK报文段时
表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接

---

抓包演示一下：