【网络】Udp & Tcp

た入场券 2023-03-12 07:10 41阅读 0赞

文章参考：图解TCP/IP第五版

### TCP/IP协议中Udp、Tcp协议 ###

*   *   *  1. 端口
         *  2. UDP协议
         *   *   *  2.1 协议格式
                 *  2.2 特性
                 *  2.3 应用场景
         *  3. TCP协议
         *   *   *  3.1 协议格式
                 *  3.2 特性

### 1. 端口 ###

**1.1 端口号的作用**

*  端口号可以用来标识同一个主机上通信的不同应用程序，端口号+IP地址就可以组成一个套接字，用来标识一个进程。
 *  在TCP/IP协议中，用“源IP地址”,“目的IP地址”,“源端口号”,“目的端口号”,“协议号”的一个五元组来标识一个通信。

**1.2 端口范围划分**

*  0~1023：知名端口号，是留着备用的，一把都是用于协议，例如HTTP、FTP、SSH;
 *  1024~65535：是操作系统动态分配的端口号，客户端程序的端口号，就是由操作糸统从这个范围来分配的，在TCP与UDP的套接字通信中，客户端的端口号就是在此范围中。

**1.3 知名的端口号与端口号对应的服务器**

*  HTTP服务器：80；
 *  HTTPS：443；
 *  FTP服务器：21；
 *  TELNET服务器：23；
 *  SSH服务器：22；
 *  WEB服务器：25。

**1.4 问题**

（1）一个进程是否可以bind多个端口号？ 可以
    
    （2）一个端口号是否可以被多个进程绑定？ 不可以

### 2. UDP协议 ###

##### 2.1 协议格式 #####

*  16源端口/16目的端口/16数据报长度/16校验和；
 *  16位源端口/目的端口：负责端与端之间的数据传输；
 *  16位udp数据报长度：包含头部在内，udp数据报长度 ；
 *  16位udp数据校验和：校验数据一致性----二进制反码求和算法；  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70]

##### 2.2 特性 #####

**2.2.1 无连接、不可靠**

*  客户端只需要知道服务端的地址信息就可以直接发送数据，并且不关心数据是否已经到达；
 *  知道对端的IP和端口号就直接进行传输，不需要建立连接。

**2.2.2 面向数据报**

*  udp整个数据报长度不能大于64k，若大于的话，两个字节就不够存；
 *  因为udp数据包长度的限制，若数据过大时，则需要用户在应用层进行数据分包，将大数据报分割成一个个小的数据报64k；
 *  udp不能保证数据可靠、有序到达，因此需要用户在应用层进行包序管理；
 *  udp在sendto发送数据时将数据放到发送缓冲区，则会直接封装头部，将数据发送出去。

##### 2.3 应用场景 #####

![在这里插入图片描述][20200515222844521.png]

### 3. TCP协议 ###

##### 3.1 协议格式 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 1]

*  源/目的端口：负责端与端数据传输
 *  序号/确定序号：进行包序管理
 *  长度：头部长度，以4字节为单位，表示tcp头部最小为20字节，最大为60字节
 *  标志位：URG/ACK/PSH/RST/SYN/FIN
 *  窗口大小：用于避免丢包的一种方式
 *  校验和：校验数据一致性----二进制反码求和
 *  紧急指针：带外数据
 *  选项数据：通常用于通信双方协商一些数据的时候使用

##### 3.2 特性 #####

**3.2.1 面向连接**

*  tcp是一个有状态的协议，三次握手建立连接，四次挥手断开连接；
 *  通信双方之间要先建立连接。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 2]
 *  ACK： 确认号是否有效；
    
     *  当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知，这个消息叫做确认应答（ACK）。
 *  SYN：请求建立连接，把携带SYN标识的称为同步报文段；
 *  FIN：通知对方, 本端要关闭了, 把携带FIN标识的为结束报文段；

【问题：为甚什么建立需要三次？断开需要四次？】

(1)握手过程为什么是三次？
    
    tcp是全双工通信，必须确保双方都有数据收发的能力，两次不安全，四次没必要；
    客户端发送SYN请求之后，若万一退出服务端却不进行再一次确认，就会丢包；
    第一次SYN因为网络延迟与后发的第二个SYN同时到来，会造成服务端创建多余的socket。
    
    (2)挥手过程为什么是四次？
    
    套接字的关闭有好多操作,可以分别关闭套接字的读和写;
    当关闭套接字写操作，会触发向对端发送FIN包，接收方收到FIN之后，认为对方不再继续发送数据，因此recv会返回，等待用户关闭套接字，关闭套接字则会给对方发送FIN；
    在发送端若只关闭了写端，并没有关闭套接字读端，意味着对方有可能还正在发送数据，自己有可能还需要接收，因此ACK和FIN不能一起发送，否则自己在有些数据还没有接收成功的情况下收到了FIN，则会造成有数据还没有处理完，或者对端有数据没有发送完毕，因此握手三次，挥手必须得四次。

**3.2.2 可靠传输**

*  确认应答机制----发送的每一条数据要求对方进行确认回复
 *  超时重传机制----等待确认回复超时，则重发数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 3]
 *  协议字段中的序号/确认序号  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 4]
 *  协议字段中的校验和 – 若数据不一致，则丢弃数据要求重传
 *  面向连接 – 可靠传输的前提

**避免丢包**

【滑动窗口机制】

*  通过一个窗口后沿和一个窗口前沿以及一个当前的发送序号，通过这几个序号就可以维护一个窗口；
 *  发送窗口：前沿减去后沿不大于窗口大小 --> 前沿 - 后沿 <= 窗口大小；
 *  接收窗口：窗口大小不大于缓冲区中空闲空间大小 --> 窗口大小 <= 缓冲区中空闲空间大小  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 5]  
    优点：
    
    1.  发送方可以连续发送多条数据，等待对方回复，提高一定的传输性能；
    2.  连续发送数据，连续接收确认回复，可以避免因为确认回复的丢失而导致数据重传；

【快速重传机制】

*  当接收方接收到第二条数据，而还未接收到第一条数据，则这时认为数据有可能丢失，因此连续发送三次对应数据的重传请求；
 *  当发送方连续接收到三条重传请求，才会将相应数据进行重传，避免数据因为网络原因而延迟到达的重传。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 6]

**3.2.3 面向字节流**

*  有序、可靠、双向的、基于连接的字节流传输；
 *  tcp通信双方在进行三次握手的时候，会协商一个信息 – MSS；
 *  tcp在发送数据，会将数据先放入发送缓冲区，操作系统从缓冲区中取出合适大小（MSS：最大数据段大小，不包括头部）的数据封装报头进行数据传输；数据到达对端之后tcp分用之后，将数据放入接收缓冲区中，用户recv从缓冲区取出想要的大小的数据。
    
     *  优点：数据传输比较灵活，但是会有一种情况：在缓冲区tcp有可能会将多条数据当作一条处理 – tcp粘包。
     *  tcp的粘包本质：tcp在传输层对数据边界并不敏感，多条数据合成一条数据进行处理；粘包有可能在发送方产生也有可能在接收方产生。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70]: /images/20230312/4fda81df2b624aa88edd68625c7b63b4.png
[20200515222844521.png]: /images/20230312/c4ad3c63b6354ffa8ba34313e6fc0e1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 1]: /images/20230312/3750d82daf8546c59aedb0d1473eaecd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 2]: /images/20230312/ae5aed0245a543e39ad822c805b86694.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 3]: /images/20230312/9a65d221cae7411490d945a92fa3444d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 4]: /images/20230312/d634f8c44026403bac21294a8217d94e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 5]: /images/20230312/e7683abb11c546248a7d1a5584098d0b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMjg2Mzcz_size_16_color_FFFFFF_t_70 6]: /images/20230312/7af7f71112f7436e938bae3e5dd7e18d.png