UDP/TCP协议

网络层只负责将数据包送达至目标主机，并不负责将数据包上交给上层的哪一个应用程序，这是传输层需要干的事，传输层通过端口来区分不同的应用程序。传输层协议主要分为UDP（用户数据报协议）和TCP（传输控制协议）

端口

端口可以认为是一台主机上一个进程的标识，这与进程ID一样，只不过端口是网络层面中的概念，而进程ID是操作系统层面的概念。有了端口号，传输层就可以判断应该将数据包交付于哪一个上层应用。

UDP 用户数据报协议

UDP是一种面向数据报、无连接、不可靠但是传输速度快的传输协议。
面向数据报：应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并(如果一次sendto是100字节，那么对端一次recvfrom也必须一次100字节)
无连接：发送端主机不会检测目标主机是否可接受数据报文，知道IP和PORT后直接将数据发送给目标主机
不可靠：无论数据包是否到达目标主机，发送主机不做任何处理(部分丢包)
传输速度快:无连接、不可靠的特点让UDP的实现比TCP简单得多，没有那么多的管理成本

UDP缓冲区

UDP 没有发送缓冲区，只要应用层将数据交付给UDP，那么UDP直接将数据包封装后交给内核处理。
UDP 具有接受缓冲区，只是简单地存放收到的数据包(无序的)，缓冲区满了则不再接受数据包(新的报文丢弃)

UDP报文格式

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/ece57ad02f914efa84afe92031ce2e0e.png
16位报文长度包含报首的6字节

POSIX标准中提供的UDP读写接口

读取UDP报文 recvfrom
发送UDP报文 sendto

TCP 传输控制协议

TCP通过确认应答，超时重传等机制确保了数据报文的可靠传输，通过滑动窗口、延迟应答等机制确保较高的效率，通过流量控制和拥塞控制确保网络环境的通畅，代价是大大提高了管理成本，传输速度逊色于UDP

POSIX标准中提供的TCP读写接口

recv读取TCP报文
send发送TCP报文

TCP确认应答

为了保证数据包正确到达目标主机端口，TCP规定当目标主机收到报文时需要向源主机发送ACK应答，告诉源主机我已经收到了数据
在这里插入图片描述

序列号

网络环境复杂多变，不能保证数据包都可以严格按照发送顺序到达目标主机，但是由于TCP需要保证可靠传输，它必须对这些无序的数据包进行排序再向上层交付，TCP借助序列号的方式标识顺序

发送端需要在TCP报首中写入序列号，序列号为相对正文起始的偏移量
接受端在发送确认应答时在TCP报首中写入确认序列号，表示已经收到了该序列号之前的所有数据，同时确认序列号也告诉发送端下一次该从偏移量为多少处开始发送

在这里插入图片描述

TCP超时重传

我们先假设TCP是串行发送数据报文的,即只有收到最近一次数据包的ACK应答才会继续发送数据给目标。在网络传输过程一定会存在数据包丢失的情况发生，要么是数据包本身丢失，要么是ACK应答丢失，无论哪种情况，发送端都需要对异常进行处理。
如果在一定时间内没有收到目标主机发来的ACK应答，就判定此次数据发送失败，进行重新发送
在这里插入图片描述

滑动窗口

如果数据是串行发送的话，由于每一次都需要等待对端应答，网络的传输速度是相对较慢的，这会造成极大的延迟，大大降低传输效率，TCP引入滑动窗口机制来批量的发送数据
窗口分为已确认数据，未确认数据，未发送数据
一次批量发送数据后增加窗口的长度
收到ACK应答后缩小窗口长度
在这里插入图片描述

滑动窗口允许部分应答丢失

引入了滑动窗口之后，发送端不再需要串行的发送数据报文，可以一次发送多个数据报文，并且允许部分应答丢失
在这里插入图片描述

滑动窗口数据本身丢包如何解决

如果批量发送的数据包部分丢失，发送端可以根据对端的应答报文中的确认序列号进行重发，如果收到了3此确认序列号相同的应答报文，就认为出现了丢包，触发快重传机制，快重传和超时重传相互配合，保证可靠性（超时重传用于兜底最后一个应答未收到的情况）

快重传

在这里插入图片描述

流量控制

TCP是具有发送缓冲区和接受缓冲区机制的，虽然引入采用滑动窗口的机制使得发送端可以一次性发送多个数据包，但这并不意味着发送数据包的个数是可以任意的，必须考虑到对端接受缓冲区的承载能力，，如果对端告知接受缓冲区快要不足时，发送端应该减少单次数据发送量或是阻塞等待；对端接受缓冲区的大小通过TCP报文中的窗口大小字段来表明
在这里插入图片描述
当接收端的窗口空闲后会向发送端发送窗口更新通知报文，告知可以恢复通信，但是这个报文可能会丢失，就需要依靠发送端的窗口探测机制来兜底了，如果长时间收不到窗口更新通知，发送端为认为窗口更新通知在网络中丢失，此时会向对端发送窗口探测请求，对端接受后会再次发送窗口更新通知

TCP连接管理

TCP是面向连接的，主机间通信必须先建立连接，否则无法通信。客户端如果想要和服务端通信，需要向服务端发送请求，收到服务端应答之后建立连接开始通信，当某一端断开连接时，也需要发送结束请求进行同步。建立TCP连接的过程为3次握手，断开TCP连接的过程为4次挥手
在这里插入图片描述

TIME_WAIT

主动断开连接的一方需要进入TIME_WAIT状态，只有经过一定时间后才能真正关闭套接字文件描述符，之所以要进行time wait等待是避免端口被复用时收到之前的残余数据，time wait的具体时间通常为2MSL（TCP最大生存时间），经过2MSL时间后可以确保该该端口最近一次连接的数据已经全部消散(要么已经被接受，要么丢包)

全连接队列

POSIX提供的TCP监听接口listen的第二个参数为允许建立连接的最大数量，内核将处于established状态但未被应用层所使用的套接字以链表方式级联，称为全连接队列（为established之前称为半连接队列），过多的连接增加服务器的负担，因此在开发过程中应该选择一个合适的阈值

拥塞控制

有了滑动窗口，收发主机之间能够连续发送大量数据包。然而，如果在通信刚开始时就发送大量数据，可能会引发网络拥堵的问题。一般来说，计算机网络都处在一个共享环境中，因此有可能因为其他主机之间的通信使得网络变得拥堵，在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能导致网络瘫痪。TCP为了防止网络瘫痪，在通信一开始时会通过慢启动算法进行控制数据发送量。
为了在发送端调节所要发送数据的量，定义了一个叫做拥塞窗口的概念。在慢启动的时候，将拥塞窗口大小设置为1个数据包(1 MSS)的大小发送数据，每次收到一个ACK应答，拥塞窗口增加1 MSS，在发送数据包时，将拥塞窗口大小与接收端窗口大小取小作为发送的数据量。如果触发了超时机制，就认为发送数据量过大了，已经出现了网络拥堵，此时将拥塞窗口归置为1MSS
在这里插入图片描述
拥塞窗口的大小时呈现指数级增长的，为了避免指数爆炸的问题，引入了慢启动阈值的概念，如果窗口大小超过了慢启动阈值，之后便以线性方式增长

延迟应答

接受主机如果每次都立刻恢复确认应答，可能会返回一个较小的窗口（刚接收完数据，缓冲区已满），但其实窗口可能在很短的时间内就会有大量空闲空间，如果此时发送端收到了缓冲区已满的通知，会减少数据发送量从而降低网络利用率。解决这个问题的办法就是收到数据后并不立即返回确认应答，而是延迟一段时间。(延迟时间根据平台而定)

此外并不是每收到一个报文都是需要ACK应答的，只需要返回确认序列号最大的那个应答报文就可以告知发送端之前的数据已经接收，从而减少网络中冗余数据报文的个数。TCP传输中绝大多数是以2个数据报文为单位返回一次确认应答
在这里插入图片描述

捎带应答

在延迟应答的基础上,很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器发送了SYN请求连接时, 服务器也会给客户端回一个ACK确认应答，那么这个时候服务器请求与客户端的SYN请求连接就可以搭顺风车, 和服务器回应的 ACK一起回给客户端（三次握手中的第二次握手）

面向字节流

创建一个TCP的socket, 内核中为socket创建一个发送缓冲区和一个接收缓冲区;

调用write时, 数据会先写入发送缓冲区中; 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出; 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是到达内核的接收缓冲区; 然后应用程序可以调用read从接收缓冲区拿数据;

不想UDP一样每一次收发必须以一个数据报进行收发，TCP写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节; 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次 read一个字节, 重复100次。对于应用层而言TCP包就是一串连续的字节序列，它是否是一个完整的报文是未知的。

粘包问题

由于UDP是面向数据报的，意味着报文有很明确的数据边界.站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"或“一个半”的情况，因此不存在粘包问题
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.站在应用层的角度, 看到的只是一串连续的字节数据.那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是不是一个完整的应用层数据包(可能多了，可能少了)

降低粘包概率