代码收藏家 UDP协议与TCP协议：网络基础中的传输层
再谈端口号
端口号(Port)标识了一个主机上进行通信的不同的应用程序
在TCP/IP协议中，用 “源IP”， “源端口号”， “目的IP”， “目的端口号”， “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看)
端口号范围划分
有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号：
执行下面的命令, 可以看到知名端口号
cat /etc/services
我们自己写一个程序使用端口号时, 要避开这些知名端口号
一个进程是否可以bind多个端口号? 一个端口号是否可以被多个进程bind?
进程与端口号的关系就是父与子的关系，父亲可以有多个儿子，而每个儿子只有一个父亲。进程可以bind多个端口号，一个端口号只能被一个进程bind。
netstat
netstat是一个用来查看网络状态的重要工具
语法：
netstat +[选项]
功能：查看网络状态
常用选项：
pidof
在查看服务器的进程id时非常方便
语法：
pidof +[进程名]
功能：通过进程名, 查看进程id
UDP
UDP的特点
UDP传输的过程类似于寄包裹，你只能一个一个寄，而不能寄1.5个。
面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并；
用UDP传输100个字节的数据：
如果发送端调用一次sendto，发送100个字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节；而不能循环调用10次recvfrom，每次接收10个字节；
UDP的缓冲区
UDP的socket既能读，也能写，这个概念叫做 全双工
我们用的网络lO接口，其实并不直接是发送和接受接口，而是拷贝接口!
协议就是结构化数据
UDP使用注意事项：
基于UDP的应用层协议
当然，也包括你自己写UDP程序时自定义的应用层协议;
TCP
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;
认识TCP协议的报头
URG：紧急指针是否有效
ACK：确认号是否有效
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段
-
tcp协议是有标准长度的:20，先读取20字节
-
转换成为一个结构化的数据，立马提取标准报头中的4位首部长度
-
就能得到后续报头的剩余大小，x * 4 – 20 = 0; x * 4 – 20 = n;
tcp报头的总长度，0000-1111，[0，15]
tcp报文的总长度 = 4位首部长度 * 4字节
tcp报头的总长度，0000-1111，[0,15]，[0，60]，[20,60]
如果我们报头就是20字节，那么4位首部长度，应该填写多少呢?
x * 4字节 = 20 、x = 5 （0101） -
只要把tcp报头处理读取完毕，剩下的就是有效载荷
理解封装解包
我们收到一个报文，是如何找到曾经bind特定port的进程的？网络协议栈和文件是什么关系？
系统有很多的场景需要我们快速定位一个进程，bind就是将端口号及映射关系插入哈希表中。
理解可靠性
为什么网络传输的时候，会存在不可靠问题？
因为距离变长了，导致出现可靠性问题。
不可靠问题常见都有哪些不可靠的场景?
丢包，乱序，校验错误，重复…
如果距离长了，存不存在绝对的可靠性？
比如：小明小红相隔1千米，小明问小红吃饭了吗？这条消息，小明并不能确定小红是否收到。小红回小明：她吃了。这时候小明才能确定她收到了这条消息。
不存在绝对的可靠性，存在相对的可靠性，一个报文只要收到了应答就能保证该报文的可靠性 – 建立在确认应答上
TCP工作模式
双方两个朝向的可靠性，双方在进行通信的时候，可能除正常的数据段，通信时也会涵盖确认数据段
tcp双方的地位是对等的，只需要搞定一个朝向的通信过程
数据到达对面的顺序一定是和发送的顺序一样的吗?不一定
注定了应答报文，对应的报头中必定涵盖了确认序号，确认应答和确认序号：接收方已经收到了ACK序号之前的所有（真的所有，且连续）的报文。
为什么我们要有两组序号？
是因为我们tcp通信是全双工的，收发分别对应序号与确认序号：
16位窗口大小
因为我们所构建的所有TCP报文都是要给对方发送的，对客户端与服务端一样适用。很明显如果我们知道了对方的缓冲区大小，我们也不需要发送过去了。互相交换接受能力。
6位标志位
tcp报文也是有类型的，服务器会收到各种各样的tcp报文，接收方要根据不同的tcp报文，要有不同的动作。tcp正常的数据段，有的就是ack…
URG
URG（紧急）标志位
URG（Urgent）标志位用于指示 TCP 数据包中是否包含紧急数据。它被设置为1时，表示该数据包中的某些数据被标记为紧急数据。紧急数据指示了一种需要尽快处理的情况，通常是一些优先级较高的数据。
当 URG 标志位被设置为1时，还需要使用16位的紧急指针字段（Urgent Pointer）来指示紧急数据在数据流中的位置。紧急指针指示了紧急数据的字节偏移量，从而使接收方能够识别和处理这些紧急数据。
这些紧急数据可以称为带外数据
在 TCP 中，带外数据通过使用紧急指针（Urgent Pointer）和 URG（紧急）标志位来标识和处理。当发送端发送带外数据时，它会设置 URG 标志位，并指定紧急指针的位置，以通知接收端有紧急数据需要处理。接收端在收到带有 URG 标志位的数据时，会根据紧急指针指示的位置来处理这些带外数据。
带外数据的使用可以根据具体的应用协议和实现进行定义。一些常见的应用包括：
URG 标志位主要用于紧急数据的通信和处理。当 TCP 连接的一方发送紧急数据时，它可以使用 URG 标志位来通知接收方，以便接收方能够及时处理这些数据。在实际应用中，紧急数据的处理方式和含义可以根据具体的应用协议和实现进行定义。
需要注意的是，URG 标志位的具体使用和处理是由应用层协议和操作系统决定的。因此，不同的应用程序和操作系统可能有不同的处理方式和行为。
ACK
ACK（确认）标志位
ACK（Acknowledgment）标志位用于指示 TCP 数据包中的确认号（Acknowledgment Number）字段是否有效。它被设置为1时，表示 TCP 数据包中的确认号字段包含有效的确认信息。
在 TCP 连接中，数据的传输是通过发送方将数据分割为多个 TCP 数据包并发送，接收方接收到这些数据包后会发送确认信息给发送方。确认信息中包含了接收方期望收到的下一个字节的序号，即确认号。通过设置 ACK 标志位为1，发送方可以知道接收方已经成功接收到了之前发送的数据。
TCP将每个字节的数据都进行了编号：即为序列号，每一个ACK都带有对应的确认序列号， 意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发
我们把TCP里的发送缓冲区当做数组，只要将数据从应用层拷贝到了发送缓冲区，每个字节就天然有了序列号。
ACK 标志位在 TCP 的三次握手过程中也起到了重要的作用。在建立 TCP 连接时，客户端和服务器之间会互相发送带有 SYN（同步）和 ACK 标志位的数据包，用于确认连接的建立和同步序号的交换。
需要注意的是，ACK 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接中，发送方和接收方会根据 ACK 标志位的设置来确认数据的传输情况，并进行相应的处理。
PSH
PSH（Push）标志位
PSH（Push）标志位用于指示 TCP 数据包中的数据应该被立即推送给应用层，而不是等待缓冲区填满或等待计时器超时。当 PSH 标志位被设置为1时，发送方通知接收方应该立即将接收到的数据提交给上层应用进行处理。
通常情况下，TCP 数据报在发送方的缓冲区中进行累积，直到缓冲区填满或者等待一定的时间才会发送出去。这种方式可以提高网络传输的效率，因为可以将多个数据报一起发送。但在某些情况下，需要立即将数据推送给接收方的应用层。
例如，在实时通信或交互式应用中，延迟会对用户体验产生不利影响。通过设置 PSH 标志位为1，发送方可以指示接收方在接收到该数据报后立即将数据提交给应用层处理，从而减少传输延迟。
需要注意的是，PSH 标志位的具体使用和处理是由应用层协议和操作系统决定的。应用程序和操作系统可以根据自身需求来决定何时设置 PSH 标志位，以满足特定的数据传输要求。
RST
RST（复位）标志位
RST（Reset）标志位用于指示 TCP 数据包中的复位请求。当 RST 标志位被设置为1时，它表示发送方或接收方希望立即中断当前的 TCP 连接，并进行连接的复位操作。
RST 标志位通常用于表示发生了严重的错误或异常情况，导致当前的连接无法继续进行。当一方发送带有 RST 标志位的 TCP 数据包时，它相当于向对方发送了一个连接复位请求，要求对方放弃当前的连接并重新建立新的连接。
RST 标志位的使用场景包括：
需要注意的是，RST 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在收到带有 RST 标志位的数据包时，接收方会根据协议规定的处理方式来中断连接并进行相应的处理。
SYN
SYN（同步）标志位
SYN（Synchronize）标志位用于在建立 TCP 连接时进行同步和协商。在 TCP 的三次握手过程中，SYN 标志位扮演了重要的角色。
当发送方希望建立一个新的 TCP 连接时，它会发送一个带有 SYN 标志位的数据包给接收方。这个数据包中包含一个初始序列号（Initial Sequence Number），用于标识数据流的起始位置。通过设置 SYN 标志位为1，发送方告诉接收方它希望建立一个新的连接，并将初始序列号设置为指定的值。
接收方收到带有 SYN 标志位的数据包后，会发送一个带有 SYN 和 ACK（确认）标志位的数据包作为回应。这个数据包中包含确认号（Acknowledgment Number）字段，表明接收方期望收到的下一个字节的序号，并且也包含一个自己选择的初始序列号。
最后，发送方收到接收方的 SYN+ACK 数据包后，会发送一个带有 ACK 标志位的数据包作为确认。这个数据包中的确认号字段表示发送方期望接收到的下一个字节的序号。
通过这个三次握手的过程，发送方和接收方可以建立起双向的、可靠的 TCP 连接，并同步序列号和确认号，以确保数据的可靠传输。
需要注意的是，SYN 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接的建立过程中，发送方和接收方会根据 SYN 标志位的设置和响应来完成连接的建立和同步操作。
FIN
FIN（结束）标志位
FIN（Finish）标志位用于表示发送方已经完成发送数据，并且要求关闭连接。当一个 TCP 连接的一方发送带有 FIN 标志位的数据包时，它表示它已经没有更多的数据要发送，并且希望关闭连接。
FIN 标志位的使用场景包括：
当一方收到带有 FIN 标志位的数据包时，它会发送一个带有 ACK（确认）标志位的数据包作为确认，表示已经收到关闭请求。然后，它也可以选择发送带有 FIN 标志位的数据包，表示它也已经完成发送数据，并请求关闭连接。
通过这种方式，双方可以逐步关闭连接，确保双向的数据都已经发送完毕，并最终关闭连接。
需要注意的是，FIN 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接关闭过程中，发送方和接收方会根据 FIN 标志位的设置和响应来完成连接的逐步关闭。
如有错误或者不清楚的地方欢迎私信或者评论指出🚀🚀
