HCIA---TCP/UDP协议
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
-
目录
文章目录
一.UDP协议简介
UDP协议的特点：
二.TCP协议简介
TCP协议特点
三.TCP和UDP的区别
四.TCP/IP结构详解
五.TCP运输连接的阶段
编辑
TCP连接建立过程---TCP三次握手
TCP三次握手总结：
TCP四次挥手：
思维导图
一.UDP协议简介
UDP（User Datagram Protocol，用户数据报协议）是一种轻量级的传输层协议，在计算机网络中使用。与TCP协议不同，UDP协议不保证数据传输的可靠性和顺序性，但它具有较低的延迟和较少的网络开销。UDP协议通常被用于需要实时性较高的应用程序，如音频、视频、游戏等。
UDP协议的数据传输采用数据包的形式，每个数据包包含源端口号、目的端口号、数据长度和数据内容等信息。UDP协议没有连接的概念，因此在数据传输过程中，源端和目的端之间没有建立任何状态。由于UDP协议不需要维护连接状态和各种控制信息，因此在网络中的开销比TCP协议小。但是，这也意味着UDP协议没有对数据传输的可靠性和顺序性进行保障，因此需要应用程序自行实现相关处理机制。
UDP协议的优点是速度快、网络开销小，适用于对数据传输实时性要求较高的应用场景；缺点是不保证数据传输的可靠性和顺序性，需要应用程序自行处理相关问题。因此，在选择使用UDP协议时需要根据具体应用场景的需求进行权衡。
UDP协议的特点：
1. 面向无连接：UDP协议是一种非面向连接的协议，发送数据之前不需要建立连接，也不需要维护连接的状态。因此，UDP协议的速度比TCP协议更快，但可靠性较低。
2. 简单、轻量级：UDP协议的头部较短，只有8个字节，相比之下TCP协议的头部有20个字节，因此UDP协议的数据包更小，传输效率更高。
3. 不可靠：UDP协议不提供可靠的数据传输机制，数据包可能会丢失、重复、乱序等，因此应用程序需要自己进行错误检测和重传等操作。
4. 支持广播和多播：UDP协议可以将数据包传输给多个主机，支持广播和多播功能。
5. 适用于实时应用：由于UDP协议传输数据速度快，数据包较小，因此适用于实时应用，如视频流、音频流等。
6. 不支持拥塞控制：UDP协议不支持拥塞控制，当网络拥塞时，UDP协议可能会导致数据包丢失或网络负载过高。
二.TCP协议简介
TCP（Transmission Control Protocol，传输控制协议），是一种面向连接的、可靠的、基于字节流的传输协议。TCP协议被广泛用于Internet上的通信，它在应用层和IP层之间提供可靠的数据传输服务。
TCP协议特点
1.面向连接：为了确保可靠性和有序性，TCP协议在数据传输之前需要建立连接，数据传输完成后需要断开连接。
2.可靠性：TCP协议可以确保数据的可靠性，它使用确认应答机制，如果发送方的数据没有被接收方正确接收，TCP协议会重新发送数据，直到接收方正确接收为止。
3.流式传输：TCP协议以字节流的方式传输数据，没有数据记录的界限，可以根据需要动态地调整数据传输的大小。
4.拥塞控制：TCP协议可以根据网络情况动态地调整数据传输的速率，避免网络拥塞。
5.数据传输有序：TCP协议可以确保数据按照发送的顺序传输，不会出现乱序的情况。
6.面向字节流：TCP协议以字节流的方式传输数据，没有数据记录的界限，可以根据需要动态地调整数据传输的大小。
三.TCP和UDP的区别
| TCP协议 | UDP协议 |
| 面向连接协议 | 无连接协议 |
| 传输可靠 | 传输不可靠 |
| 可以进行流控 | 不可进行流控 |
| 可以分段 | 不可分段 |
| 传输速度慢，占用资源大 | 传输速度快，占用资源小 |
四.TCP/IP结构详解
源端口号和目的端口号（寻址）：与udp中类似，用于寻找发端和收端应用进程这两个值加上IP 首部中的源端IP地址和目的端IP地址唯一确定一个，在网络编程 中，一般一个IP地址和一个端口号组合称为一个套节字
序号（seq）：用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的第 一个数据字节。在tcp中tcp用序号对每个字节进行计数（这个值与发送的帧数没有 关系，而是与发送的数据字节数有关系
确认序号（seq+1）：包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上 次已成功收到数据字节序号加 1（不是单纯的序号加1，还包括数据字节 数）。
首部长度：用于记录tcp数据报首部的长度，一般为20字节，实际值为首部长度除以4。
| URG | 紧急指针（ urgent pointer）有效。 |
| ACK | 确认序号有效。 |
| PSH | 接收方应该尽快将这个报文段交给应用层。 |
| RST | 重建连接。 |
| SYN | 同步序号用来发起一个连接 |
| FIN | 发端完成发送任务。 |
窗口大小：用于流量控制。
检验和：检验和覆盖了整个的 TCP报文段： TCP首部和TCP数据，与udp相似需要计算伪首部。
五.TCP运输连接的阶段
TCP运输连接有以下三个阶段：
- 建立TCP连接，也就是通过三报文握手来建立TCP连接。
- 数据传送，也就是基于已建立的TCP连接进行可靠的数据传输。
- 释放连接，也就是在数据传输结束后，还要通过四报文挥手来释放TCP连接。
TCP连接建立过程---TCP三次握手
TCP的连接建立要解决以下三个问题：
-
1、使TCP双方能够确知对方的存在 。
-
2、使TCP双方能够协商一些参数（ 最大窗口值是否使用窗口扩大选项和时间戳选项，以及服务质量等）。
-
3、使TCP双方能够对运输实体资源（例如缓存大小连接表中的项目等）进行分配。
这是两台要基于TCP进行通信的主机：
-
主动发起TCP连接建立称为TCP客户(client)。
-
被动等待TCP连接建立的应用进程称为TCP服务器(server)。
我们可以将TCP建立连接的过程比喻为”握手“，“握手”需要在TCP客户端和服务器之间交换三个TCP报文段。
最初两端的TCP进程都处于关闭状态。
一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。 例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等。之后就准备接受TCP客户进程的连接请求， 此时TCP服务器进程就要进入监听状态等待TCP客户进程的连接请求。
TCP客户进程也是首先创建传输控制块，然后再打算建立。 TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此称为被动打开连接。
TCP连接时向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。
TCP 连接请求报文段首部中的同步位SYN被设置为1，,表明这是一个tcp连接请求报文段。
序号字段seq被设置了一个初始值x作为TCP客户进程所选择的初始序号。
由于TCP连接建立是由TCP客户进程主动发起的，因此称为主动打开连接。 请注意TCP规定SYN被设置为1的报文段不能携带数据但要消耗掉一个序号。
TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。
1.该报文段首部中的同步位SYN和确认位ACK 都设置为1，表明这是一个TCP连接请求。
2.序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。
3.确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号seq的确认。
请注意这个报文段也不能携带数据，因为它是SYN被设置为一的报文段但同样要消耗掉一个序号。
TCP服务器进程收到该确认报文段后也进入连接已建立状态，现在TCP双方都进入了连接已建立状态，他们可以基于已建立好的TCP连接进行可靠的数据传输了
TCP三次握手总结：
三次握手是 TCP 连接的建立过程。在握手之前，主动打开连接的客户端结束 CLOSE 阶段，被动打开的服务器也结束 CLOSE 阶段，并进入 LISTEN 阶段。随后进入三次握手阶段：
① 首先客户端向服务器发送一个 SYN 包，并等待服务器确认，其中：
1.标志位为 SYN，表示请求建立连接；
2.序号为 Seq = x（x 一般取随机数）；
3.随后客户端进入 SYN-SENT 阶段。
② 服务器接收到客户端发来的 SYN 包后，对该包进行确认后结束 LISTEN 阶段，并返回一段 TCP 报文，其中：
1.标志位为 SYN 和 ACK，表示确认客户端的报文 Seq 序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接；
2.序号为 Seq = y；
3.确认号为 Ack = x + 1，表示收到客户端的序号 Seq 并将其值加 1 作为自己确认号 Ack 的值，随后服务器端进入 SYN-RECV 阶段。
③ 客户端接收到发送的 SYN + ACK 包后，明确了从客户端到服务器的数据传输是正常的，从而结束 SYN-SENT 阶段。并返回最后一段报文。其中：
1.标志位为 ACK，表示确认收到服务器端同意连接的信号；
2.序号为 Seq = x + 1，表示收到服务器端的确认号 Ack，并将其值作为自己的序号值；
3.确认号为 Ack= y + 1，表示收到服务器端序号 seq，并将其值加 1 作为自己的确认号 Ack 的值。
4‘随后客户端进入 ESTABLISHED。
当服务器端收到来自客户端确认收到服务器数据的报文后，得知从服务器到客户端的数据传输是正常的，从而结束 SYN-RECV 阶段，进入 ESTABLISHED 阶段，从而完成三次握手。
TCP四次挥手：
你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
为什么挥手需要四次？
再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。
关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。
