传输层典型协议--tcp、udp协议

传输层典型协议–tcp、udp协议

---

前言

在数据的封装与分用中，当数据到达每一层的时候，都会被封装或是被分用，传输层典型协议就是TCP、UDP。

tcp/ip模型	典型协议	含义
应用层	HTTP、FTP、DNS、SMTP	不同程序间有不同的数据格式
传输层	TCP、UDP	提供两端进程间的数据传输，描述了通信两端端口
网络层	IP	提供地址管理与路由选择，描述了通信两台主机的IP地址
数据链路层	ETH	提供相邻设备的数据帧传输，描述了相邻设备的mac地址
物理层	以太网协议	在物理层进行一些约定

---

一、传输层协议TCP/UDP

传输层：负责将数据从发送端传输到接收端。

1 端口号

端口号标识一个主机上进行通信的不同的应用程序。

在tcp/ip协议中，用源端IP，对端IP，源端端口，对端端口，协议这样一个五元组来标识一个通信。

通过命令netstat -n来进行查看。

端口号划分：

1. 0-1023：知名端口号，HTTP、SSH等这些广为使用的应用层协议其端口号都是固定的。
2. 1024-65535：操作系统动态分配的端口号，客户端程序端口号，就是在此范围来进行分配。

知名端口号：

1. SSH服务器：22端口
2. FTP服务器：21端口
3. telnet服务器：23端口
4. HTTP服务器：80端口
5. HTTPS服务器：443端口

★ 查看知名端口

cat /etc/services

netstat

netstat：是一个用来查看网络状态的一个工具。

选项	含义
-n	拒绝显示别名，能显示数字的全部转化成数字
-l	只列出有在监听listen的服务状态
-p	显示建立相关链接的程序名
-t	只显示tcp相关选项
-u	只显示udp相关选项
-a	显示所有选项，默认不显示listen相关

★ 通过进程名查看进程id

pidof [进程名]

二、UDP协议

1 协议格式

vi /usr/netinet/udp.h

在数据进行校验的时候，采用二进制反码求和算法。

二进制反码求和算法：
发送方发送数据的时候先将校验和置0，然后从报头开始逐字节取反相加，高出16位的部分截断与低16位继续相加，直到数据报结束。得到一校验和然后填充到校验和字段中进行发送；对方在收到数据之后，从报头开始进行二进制反码求和，若最终结果为0那么数据就一致，反之不一致。

2 协议特性

udp特性：

1. 无连接
2. 不可靠
3. 面向数据报传输

2.1 无连接

相较于tcp来说，其并不需要进行连接才能通信，只要知道对方的地址信息就可以直接发送数据。

2.2 不可靠

传输过程中，不保证数据安全且有序的到达对端。

2.3 面向数据报传

传输数据有最大限制，即64k-8，接收端向上进行数据的交付时必须整条交付，即udp在缓冲区取数据的时候，是先取8字节的报头，再取（长度-8）的数据出来。

udp协议特性带来的注意事点：

1. udp并不保证数据安全，有序到达对端，故需要程序员在应用层进行包序管理。
2. udp传输报文有最大大小限制，故在发送数据的时候就不能一次性发送太多数据，不然就会在应用层进行数据分包。
3. udp要求数据必须进行整条交付，故接收数据的缓冲区得足够的大，必须保证一次能接受完一条完整的数据。
4. 支持局域网的传输。

三、TCP

1 协议格式

vi /usr/netinet/tcp.h

1. 16位源端端口和16位对端端口：描述了通信的两端
2. 32位序号：tcp是面向字节流的，相对于对传输的每个字节都进行了编号，接收数据的一方会根据需要进行数据排序，最终进行数据的有序交付。
3. 32位确认序号：接收方在接收到一个数据之后，就会给发送方发送一个确认报文，报文中包括了确认序号，通过确认序号告诉对方，多少号以前的数据都已经收到了。

4. 4位报头长度：tcp报头，非固定长度，长度前20字节是固定的，只有选项数据0-40字节的不定长度。所以在解析的时候，总先取出20字节固定头部，再决定取出多少的选型数据，剩余的就是应用数据。最长60字节，最小20字节。
5. 6位保留位：暂时未使用。
6. 6位标志位：FIN、SYN、RST、PSH、ACK、URG
   FIN：断开连接请求
   SYN：SYN置1，表明是SYN请求，客户端向服务端请求建立连接
   RST：请求重新连接，通常为服务器发出重置连接请求
   PSH：提示接收端立即从缓冲区读走数据
   ACK：对请求进行确认，确认应答标志位
   URG：紧急指针应答位

7. 16位窗口大小：用于实现滑动窗口机制，进行流量控制；当接收缓冲区满的时，16位窗口大小置0。
8. 16位校验和：二进制反码求和算法，校验数据的一致性。
9. 16位紧急指针：指向了紧急数据的结束位置。

10. 0~40字节选型数据：一些协商相关信息。

• MSS：最大数据段大小，一个tcp报文的最大数据大小，在三次握手的时候接收方和发送方都会声明自己MSS，因为接收方和发送方的MTU可能是不同的，最终会以较小的MSS为准。

• MTU：链路层限制的最大传输单元，以太网默认 1500 字节

2 协议特性

tcp特性：

1. 有连接
2. 可靠
3. 字节流传输

2.1 面向连接

通信前需建立连接，确保双方都具有数据收发能力，涉及到连接管理，以及状态管理。

连接管理和随着连接为两方带来的状态迁移变化：三次握手建立连接，四次挥手断开连接。

1. 握手三次原因
   二次不安全，四次没必要，握手是为了确保数据双方都具有数据收发的能力。
2. 三次握手失败后，通信双方如何进行处理？
   ① 第一次握手失败：客户端重传SYN
   ② 第二次握手失败：服务器等待最后一次ACK超时就会发送RST，然后释放资源，客户端重发SYN
   ③ 第三次握手失败：服务器等待最后一次ACK超时就会发送RST，然后释放资源

连接断开挥手四次原因：

• FIN请求只能表示主动关闭方不再发送数据，而不代表不接收数据，故被动关闭方收到FIN请求并确认后，还是会继续发送数据。等待上层不再发送数据了，也得关闭套接字后发送FIN包。

🤔断开连接中不同状态问题：

问题一：当一台主句上出现大量的CLOSE_WAIT状态连接？

CLOSE_WAIT状态为：被动关闭方收到FIN请求且进行回复后的状态，是一种知道对方要关闭连接，但等待应用程序进行处理的状态。若主机上出现大量的CLOSE_WAIT状态连接，则是程序中并未针对要断开的连接进行close处理。

问题二：TIME_WAIT状态有啥用，直接主动关闭方为什么不直接关闭套接字资源？

TIME_WAIT状态是主动关闭方在发送最后一次ACK后进入的状态，若没有TIME_WAIT，主动关闭方会直接释放套接字资源，有可能会出现新启动的套接字使用了与之前相同的地址信息，而上一次连接可能最后一次ACK会丢失，一旦丢失被动关闭方会重传FIN，就会导致上一次通信因为最后一次ACK丢失而重传FIN包对现在的新连接造成影响。
故，不能直接释放资源，得等上2MSL（报文最大生命周期）时间，对那些可能重传FIN包的连接进行处理，保证上一次通信的所有数据都消失在当前的连接中。

问题三：当一台主句上出现大量的TIME_WAIT状态，原因，处理？

TIME_WAIT状态是主动关闭方最后一次发送ACK后进入的状态，等待一段时间是处理有可能因为ACK的丢失而导致FIN包的重传。
故，当一台主机出现大量的TIME_WAIT状态，可能是主机上大量主动地关闭了连接，常见于爬虫服务器。

解决：

1. 将TIME_WAIT时间设置短；
2. 设置地址端口重用：设置套接字选型，SO_REUSEADDR、SO_REUSEPORT,当一个连接设置了地址端口重用选项，当自己进入TIME_WAIT状态时，其它连接也可以绑定相同的地址和端口。

tcp连接管理中的保活机制：

1. 情景
   tcp通信中，若客户端与服务器的通信频率不高，当中间突然网络断开，并没有四次挥手断开连接的过程，因为通信频率不高，可能要很久才知道。
2. 保活机制
   在通信中，客户端与服务端若无长时间的通信（7200s），则 tco 服务器会自动向客户端发送保活探测心跳包，并要求对方进行响应（默认每隔75s)，若连接多次都未收到响应（默认9次），则认为连接断开。
   其默认时间次数都可以通过套接字选项来进行配置。

2.2 可靠连接

保证数据安全有序的到达对端。

安全有序实现：确认应答机制、超时重传机制、校验和、序号和确认序号。

（一）确认应答（ACK）机制：


TCP将每个字节的数据都进行了编号，即序列号。
每个回复的ACK都带有对应的确认序号，意思是告诉发送者，已经收到了哪些数据，下一次对方应该从哪里开始发送。

（二）超时重传机制：

主机A发送数据给B之后，可能以为网络状况突变等原因而导致数据无法到达主机B；若主机A在一个特定时间间隔内没有收到B发来的确认应答，就会对该条数据进行重新发送。
也有可能主机B收到了主机A发送的数据，但是回复的ACK丢失了。

故，主机B因为各种原因可能会收到很多的重复数据，而TCP协议得知道哪些是重复的包，并且把重复的包给丢弃掉，实现可利用序列号来进行重复数据的去重。

那超时时间，如何界定是超时呢？

tcp为了保证无论在何种环境下都能高性能的通信，会动态的计算该时间。

1. Linux中超时以 500ms 一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍
2. 若重发一次，得不到响应，等待 2*500ms 再进行重传
3. 若仍然得不到响应，等待 4*500ms 进行重传，依次，以等待时间以指数形式进行递增
4. 重传次数到一定程度后，tcp认为网络或者对端主机出现异常，强制进行关闭连接

（三）性能的挽回

tcp为保证可靠传输牺牲了部分传输性能，实际上，有些性能损失是没有必要的。
如：

1. 数据发送过多，导致对方缓冲区溢出而丢包
2. 因网络状况突变导致大量的丢包重传
3. 因为确认应答丢失所导致的重传

1. 数据发送过多，导致对方缓冲区溢出而丢包。

解决：滑动窗口机制，流量控制机制，避免因发送方数据过多而丢包。

★ 滑动窗口机制

滑动窗口机制：
发送端窗口维护一个发送窗口，接收端维护了一个接收窗口。

1. 作用
   进行流量控制，避免因发送方数据过多而丢包
2. 协议涉及
   协议字段中窗口大小，16位窗口大小字段，即接收方进行数据发送或者确认回复的时候，告诉对方最多给自己发送多少数据
3. 发送端发送窗口
   窗口后沿：记录了从哪个序号开始对数据进行编号发送，移动取决于是否收到了后沿数据的确认回复
   窗口前沿：记录了最多发送数据到多少序号
   窗口前沿-窗口后沿<=接收方回复的窗口大小
4. 接收端接收窗口
   窗口后沿：记录要接收数据的起始序号，移动是根据收到的起始序号的数据来决定
   窗口前沿：记录当前接收数据的结束序号，移动是根据缓冲区剩余空间大小来决定
   窗口前沿-窗口后沿<=缓冲区剩余空间大小

前面，确认应答机制我们知道，对于每一个发送的数据段，都要给一个ACK确认应答，收到ACK之后再发送下一个数据段，但这样性能就比较差，尤其当数据往返时间较长的时候。

那数据不把它一段一段进行发送和应答，而是一次发送多条数据。

窗口大小，就是无需等待接收端回复ACK应答而可以继续发送数据的最大值，图中窗口大小就是4000个字节，即四个段；发送前四个段的时候就不需要等待任何ACK，而是直接进行发送。
收到第一个段的ACK后，滑动窗口就向后移动第一个段的数据长度，然后继续发送第五个段的数据，依次进行。
操作系统内核为了维护滑动窗口，开辟了发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据才会从缓冲区中进行删除。
窗口越大，则网络的吞吐率就越高。

滑动窗口随发送数据的变动如下：

那若出现了丢包时后我们又如何进行重传呢？

情况一：ACK在回复的过程中丢失。

因为操作系统内核，为了维护滑动窗口，开辟了发送缓冲区来记录当前还有哪些数据没有应答，可以通过该缓冲区来进行确认。

情况二：数据包在传输过程中丢了。

如图，1001-2000字节的数据在传输的时候丢失了，发送端会收到1001这样的ACK，若发送端主机连续三次收到1001这样的应答，就会将对应的数据进行重新发送。

但是，接收端处理数据是速度是有限的，若发送端发送数据过快，就会导致接收端的缓冲区被写满，此时若发送端进行进行数据的发送，那么就会造成数据的丢包问题，从而丢包重传等问题。
这就需要流量控制机制来进行处理。

1. 停等协议
   发送方发送一条数据后，收到回复才会发送下一条数据，适用于网络状况较差的场景
2. 回退n步协议
   滑动窗口机制决定了tcp数据传输可以管线化传输，可以连续发送多个报文，而在传输过程中，若出现了丢包，回退n步协议，就指从丢包的这个数据开始重新对数据进行传输
3. 选择重传协议
   传输过程中，丢包的话，哪个包丢了就将哪个包进行重传，适用于网络较好的场景

★ 流量控制机制

流量控制：

1. 定义
   tcp支持根据接收端的处理能力，来决定发送端的发送速度的机制。
2. 过程

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给
  发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要
  定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

2. 因网络状况的突变导致大量的丢包重传。

解决：拥塞机制，快速重传协议，解决因网络状况突变导致大量的丢包重传。

★ 拥塞机制

TCP引入慢启动机制，即先发少量的数据，知道当前的网络拥堵状态，再决定按照多大的速度来传输数据。

拥塞机制：

1. 作用
   避免因为网络状况突变，因为网络拥塞而导致大量丢包的情况
2. 思想
   慢启动，快增长的过程进行网络探测
   
3. 拥塞窗口
   控制发送方发送数据量的一个判定基准，一般初始大小设置为1，从初始值开始进行指数级增长，达到阈值后进行线性增长。
   在传输过程中一旦出现超时重传，即出现丢包的情况，拥塞窗口的阈值就会变为当前窗口的一半大小，拥塞窗口则变为初始值1
4. 发送数据大小 <= min（滑动窗口大小，拥塞窗口大小）

★ 快速重传协议

我们知道，当发送端一直接收不到接收端的应答的话，就会在动态超时时间后进行一次次的重传操作，此过程未免是耗时的。

超时重传协议，避免每次重传都需要等待超时才进行。

接收方接收到的数据不是接收窗口起始序号的数据，则直接发送快速重传请求，即接收窗口起始序号的确认回复，间隔发送3次，接收方连续三次重传请求，则对确认序号对应的数据进行重传。
而收到3条重传请求，才对数据进行重传，这是因为要考虑数据可能只是网络延迟了，而并没有丢包的情况，故，以3次作为判断基准，给一定的缓冲时间。

★ 延迟发送机制

解决频繁的小数据发送效率较低的情况，每次发送数据，数据并不会立即被发送，而是等待一会儿。此期间可能会有更多小数据进来，小数据堆积成小数据后经过一次IO便可完成传输，较少IO次数，提高效率。

★ 延迟应答机制

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为1M，一次收到了500K的数据，如果立刻应答，返回的窗口就是500K。
但实际上，可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了，
在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M。

数量限制：每隔N个包就应答一次。
时间限制：超过最大延迟时间就应答一次。
具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms。

★ 捎带应答机制

当发送端发送请求给接收端后，原则上，接收端内核会立马返回ACK给发送端，然后再处理发送端传来的请求，计算出响应，再将响应发送给发送端。

基于延迟应答之上的捎带应答机制，接收端在接收到传来的请求时，不会立即的分会ACK，而是会等待一段时间，在这段时间里，接收端刚好可以对计算出要返回给发送端的响应，计算完毕后，要返回给发送端的ACK就会可以捎带着响应一起发送给客户端。

3. 因为确认应答丢失而导致的重传。

可靠传输：

1. 保证数据的可靠：面向连接，确认应答机制，序号，确认序号，校验和
2. 避免丢包：滑动窗口机制，拥塞机制
3. 性能挽回：快速重传协议，延迟发送机制，延迟应答机制

2.3 字节流传输

传输的时候，对数据以字节为单位进行编号进行传输，并不限制传输大小。

tcp在 send 发送数据的时候，会先将数据放到缓冲区中，然后等到发送的时候，取出合适大小的数据封装报头进行传输，接收方接收到数据之后进行解包，将数据放入到接收缓冲区。

3 tcp沾包问题

1. 沾包问题
   数据在缓冲区中堆积，将多条数据当作一条数据进行处理的过程
2. 沾包问题产生的本质原因
   数据之间缺乏边界管理

3.1 tcp沾包问题

tcp在传输层，并不管传输什么数据，只管从缓冲区取合适大小的数据进行操作，没有边界管理。

3.2 问题解决

在应用层，程序员对数据进行边界管理，即明确一条数据从哪儿开始，到哪儿结束。

（1）特殊字符间隔：需要对数据中的特殊字符进行编码，避免歧义

（2）数据定长：数据固定长度，缺点就是需要以最大长度定线，造成浪费

（3）数据采用TLV格式：在应用层头部中定义数据的长度，先取头部，根据头部中的长度，决定取多少数据，如HTTP，UDP等的做法。

udp面向数据报传输，数据有边界管理，udp的 sendto 接口发送数据，将数据放到发送缓冲区后，会立即封装头部进行发送。

---

( •̀ ω •́ ) 本节完！！！