姓名：王重月  学号：21021211019   学院：电子工程学院

转自：(30条消息) 嵌入式必备知识_Oliver.H的博客-CSDN博客_嵌入式基本知识必备

【嵌牛导读】TCP和UDP

【嵌牛鼻子】TCP和UDP的相关概念，延伸

【嵌牛提问】TCP和UDP的区别等

【嵌牛正文】

3.1 TCP UDP

3.1.1 TCP、UDP的区别

1） 连接

TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接。

UDP无连接。

2） 服务对象

TCP是点对点的两点间服务，即一条TCP连接只能有两个端点；

UDP支持一对一，一对多，多对一，多对多的交互通信。

3） 可靠性

TCP是可靠交付：无差错，不丢失，不重复，按序到达。

UDP是尽最大努力交付，不保证可靠交付。

4）拥塞控制，流量控制

TCP有拥塞控制和流量控制保证数据传输的安全性。

UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。

5） 报文长度

TCP是动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的。

UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。

6）首部开销

TCP首部开销大，首部20个字节。

UDP首部开销小，8字节。（源端口，目的端口，数据长度，校验和）

3.1.2 TCP、UDP的优缺点

从特点上我们已经知道，TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定。

3.1.3 TCP UDP适用场景

若通信数据完整性需让位与通信实时性，则应该选用TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。

3.1.4 TCP为什么是可靠连接

（1）序列号、确认应答、超时重传

数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明了它下一次需要接收的数据序列号。如果发送发迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。这个时间一般是2*RTT(报文段往返时间）+一个偏差值。

（2）窗口控制与高速重发控制/快速重传（重复确认应答）

TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制，每一个没收到确认应答的数据都要重发。

使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接收1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发；但还有种情况有可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会放过它的，会疯狂向它提醒…

（3）拥塞控制

拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口——cwnd。

慢启动：

最开始发送方的拥塞窗口为1，由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次，拥塞窗口cwnd加倍。当cwnd超过慢开始门限，则使用拥塞避免算法，避免cwnd增长过大。

拥塞避免：

每经过一个往返时间RTT，cwnd就增长1。

在慢开始和拥塞避免的过程中，一旦发现网络拥塞，就把慢开始门限设为当前值的一半，并且重新设置cwnd为1，重新慢启动。（乘法减小，加法增大）

快速重传

接收方每次收到一个失序的报文段后就立即发出重复确认，发送方只要连续收到三个重复确认就立即重传（尽早重传未被确认的报文段）。

快恢复

当发送方连续收到了三个重复确认，就乘法减半（慢开始门限减半），将当前的cwnd设置为慢开始门限，并且采用拥塞避免算法（连续收到了三个重复请求，说明当前网络可能没有拥塞）。

采用快恢复算法时，慢开始只在建立连接和网络超时才使用。

3.1.5典型网络模型，简单说说有哪些

OSI七层模型及其包含的协议如下:

物理层: 通过媒介传输比特,确定机械及电气规范,传输单位为bit，主要包括的协议为：IEE802.3 CLOCK RJ45

数据链路层: 将比特组装成帧和点到点的传递,传输单位为帧,主要包括的协议为MAC VLAN PPP

网络层：负责数据包从源到宿的传递和网际互连，传输单位为包,主要包括的协议为IP ARP ICMP

传输层：提供端到端的可靠报文传递和错误恢复，传输单位为报文,主要包括的协议为TCP UDP

会话层：建立、管理和终止会话，传输单位为SPDU，主要包括的协议为RPC NFS

表示层: 对数据进行翻译、加密和压缩,传输单位为PPDU，主要包括的协议为JPEG ASII

应用层: 允许访问OSI环境的手段,传输单位为APDU，主要包括的协议为FTP HTTP DNS

TCP/IP 4层模型包括：

网络接口层：MAC VLAN

网络层:IP ARP ICMP

传输层:TCP UDP

应用层:HTTP DNS SMTP

经典五层模型：

应用层、传输层、网络层、数据链路层、物理层

3.1.6 Http1.1和Http1.0的区别

1，HTTP/1.0协议使用非持久连接,即在非持久连接下,一个tcp连接只传输一个Web对象,；

2，HTTP/1.1默认使用持久连接(然而,HTTP/1.1协议的客户机和服务器可以配置成使用非持久连接)。

在持久连接下,不必为每个Web对象的传送建立一个新的连接,一个连接中可以传输多个对象

HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器每次都需要与服务器建立一个TCP连接，服务器完成请求后，立即断开TCP连接，也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应过程与第一次被访问时是相同的。举例在收到的HTML文档后，文档中有10个图片，每个图片都要重新再次建立连接获取，所以网速较慢的时候，我们有时会看到先出现网页，每个图片再逐一出现。

这样做的好处：简化了服务器的设计，是服务器更容易支持大量并发的HTTP请求

这样做的缺点：每请求一个文档就要有两倍RTT的开销 ，详细过程：HTTP协议首先要和服务器建立TCP连接，这需要三次握手，当三次握手的前两部分经过一个RTT完成后，客户就把HTTP请求报文作为第三次握手的第三个报文的数据发送给万维网服务器，服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。每个请求文档花费两倍的RTT时间。

HTTP/1.1支持持续连接和流水线方式

持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这条持续的连接并不局限于传输同一个页面上链接的文档，而是只要文档在同一个服务器上就可以通过这条持续的连接传送。

流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

3.1.7 URI（统一资源标识符）和URL（统一资源定位符）之间的区别

URL

URL 统一资源定位符（Uniform Resource Locator），其实就是我们访问web页面时需要输入的”网页地址“”网址“，比如：https://www.google.com/ 就是URL。

完整定义如下：

协议类型 : // 登录信息（认证） @ 服务器地址 : 端口号 / 带层次的文件路径 ? 查询字符串 # 片段标识符

htttp : // user:pass @ www.example.jp : 80 / dir/index.html ? uid=1 # ch

URI

URI 统一资源标识符（Uniform Resource Identifier），就是某个网络协议方案表示的资源的定位标识符，比如：https://www.google.com/ 也同样可以说是，在https网络协议下的一个URI。

如果想要了解 URI统一资源标识符，那么我们必须理清它和 URL统一资源定位符 之间的关系。

第一，URL统一资源定位符 是一个具体的概念，而 URI统一资源标识符 是一个抽象的概念。

第二，URL统一资源定位符 是 URI统一资源标识符 的子集，URL 属于 URI。

3.2 三次握手、四次挥手

3.2.1什么是三次握手

Client将标志位SYN（同步号）置为1，随机产生一个（序列号）seq=x，并将该数据包发送给Server，Client进入SYN_SENT(同步发送)状态，等待Server确认。

Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将（同步号）SYN和ACK都置为1，产生一个（确认号）ack=x+1，随机产生一个值（序列号）seq=y，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD(同步接受)状态。

Client收到确认应答后，检查（确认号）ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，完成三次握手，随后Client与Server之间可以开始传输数据了。

3.2.2为什么三次握手中客户端还要发送一次确认呢？可以二次握手吗？

三次握手是为了防止，客户端的请求报文在网络滞留，客户端超时重传了请求报文，服务端建立连接，传输数据，释放连接之后，服务器又收到了客户端滞留的请求报文，建立连接一直等待客户端发送数据。

服务器对客户端的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果客户端并没有收到服务器的回应呢？此时，客户端仍认为连接未建立，服务器会对已建立的连接保存必要的资源，如果大量的这种情况，服务器会崩溃。

两次不可以：

tcp是全双工通信，两次握手只能确定单向数据链路是可以通信的，并不能保证反向的通信正常

不用四次：

本来握手应该和挥手一样都是需要确认两个方向都能联通的，本来模型应该是：

1.客户端发送syn0给服务器

2.服务器收到syn0，回复ack(syn0+1)

3.服务器发送syn1

4.客户端收到syn1，回复ack(syn1+1)

因为tcp是全双工的，上边的四部确认了数据在两个方向上都是可以正确到达的，但是2，3步没有没有上下的联系，可以将其合并，加快握手效率，所有就变成了3步握手。

3.2.3为什么服务端易受到SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。

3.2.4什么是四次挥手

1.数据传输结束后，客户端的应用进程发出连接释放报文段（FIN），并停止发送数据，客户端进入FIN_WAIT_1状态，此时客户端依然可以接收服务器发送来的数据。

2.服务器接收到FIN后，发送一个ACK给客户端，确认号为收到的序列号+1，服务器进入CLOSE_WAIT状态。客户端收到后进入FIN_WAIT_2状态。

3.当服务器没有数据要发送时，服务器发送一个FIN报文，此时服务器进入LAST_ACK状态，等待客户端的确认。

4.客户端收到服务器的FIN报文后，给服务器发送一个ACK报文，确认号为收到的序列号+1。此时客户端进入TIME_WAIT状态，等待2MSL（MSL：报文段最大生存时间），然后关闭连接。

3.2.5为什么客户端最后还要等待2MSL？

2MSL意义：

1、保证最后一次握手报文能到达，能进行超时重传。

2、2MSL后，这次连接的所有报文都会消失，不会影响下一次连接。

3.2.6为什么建立连接是三次握手，关闭连接确是四次挥手呢？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

————————————————

版权声明：本文为CSDN博主「Oliver.H」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/weixin_43253519/article/details/108351553

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。