详细介绍：42.传输层协议TCP（上）

报文的理解

倘若应用层正在进行报文的解析，处理，会不会影响OS从网络中读取报文？为什么？

不会，首先，一个进程不是要运行到退了cpu才能运行其他的进程。进程有对应的时间片，时钟中断一直在进行，cpu接受到中断，cpu转而处理OS内置的中断向量表中对应的中断处理途径，进行进程调度，检查时间片，时间片耗尽了，进程会被切换。进程切换进程task_struct会保留上下文数据，不会影响下一个进程的执行。

在OS内部，一定可能会同时存在大量的报文，而这些报文，有的在传输层，有的在网络层，OS就必须管理这些报文 -> 先描述，在组织

struct sk_buff是描述报文的结构体。

head成员：指向数据区的头部

end成员：指向数据区的尾部

tail：指向应用层内容的尾部

data：指向的是当前所在层协议报头头部。

所谓的解包和分用，本质就是移动data指针在缓冲区中的指向（+-对应协议层报头的长度）

TCP结构

标准问题：

报头和有效载荷怎么分离？

TCP是不定长报头，其行携带对应的选项，不带选项报头为20字节。其结构中有4位首部长度，4位比特位取值：[0,15]，怎么表达20及以上字节呢？4位比特位，基本单位是4字节，能表示的字节数取值：[0,60]，但由于TCP最少都是20字节，取值范围是[20,60]，4位比特位取值范围[5,15]。

如何交付？16位的目的端口号

怎么没有报文大小？只有报头大小

TCP不必须也不能设置报文大小。TCP是面向字节流的，传输层只要能把报文进行解包分用传给应用层的接收缓冲区就行了，具体处理字节流，应用层怎么保证读到一个完整报文，由应用层来做。

那么既然不清楚TCP报文大小，有没有可能struct sk_buff中同时存在两个TCP报头，黏在一起了？不可能，一个struct sk_buff只存一个报文，这也是TCP不需要设置报文大小的体现。

TCP可靠性的本质

正确理解可靠性：

1）具有应答，可以保证历史消息的可靠性！（100%保证）

2）通信中，最新的报文永远没有应答，最新报文可靠性无法保证

保证可靠性，TCP核心：确认应答机制（让报文不是最新的）

确认应答理解：例如客户端向服务端发送数据，服务端必须应答，只要客户端收到了服务端的应答，就可以100%保证数据被服务端收到了。

TCP的通信过程（32位序号，32位确认序号）

客户端向服务端发送数据，服务端应答，客户端收到应答，由此可以保证客户端到服务器的可靠性。相反则可以保证服务器到客户端的可靠性（且不对应答做应答，防止无穷递归）

TCP传递报文时，更通用的过程：发送一堆请求，等待服务器应答。

TCP结构：32位序号，32位确认序号
确认序号

• 数值：确认序号 = 序号 + 1
• 表达意义：指定报文需要之前的所有信息，已经全部收到（下一次发送，从确认序号开始）

序号作用：排序，解决乱序问题（发送顺序和接受顺序不一致，UDP解决不了）

为什么会要有两个序号？

例如：客户端向服务器发送数据，服务器可能进行捎带应答（应答+信息），此时服务器TCP报头的序号填自己独立的，TCP确认序号为client序号+1。因为有捎带应答的情况，此时必须要有两个序号进行区分。

流量控制（16位窗口大小）

16位窗口大小含义：当前连接接收缓冲区剩余大小。

问题：以客户端向服务端发送数据为例，客户端向服务端发送了大量内容，服务端的接收缓冲区装满了数据。客户端再向服务端发的时候，服务端已经满了。这个资料就只能被丢弃，那么tcp怎么能保证可靠性？不影响，没有收到对应的应答，重传就完了。该做法本身没有错误，也能实现，不过问题就是这样做太耗费资源了，费尽千辛万苦送到缓冲区，结果被丢弃了，为什么服务端不早点说接收不了呢？

16位窗口大小：表示当前连接的接收缓冲区剩余大小。经过读取这个字段，客户端就可以知道服务端的接受能力了。

通过流量控制：主要解决的是效率问题，接收缓冲区剩余大小大的话，就发快一点，反之发慢一点，就能够尽可能减少资源的浪费。

标志位存在意义

标志位本质：报头中的比特位

为什么要有标志位？

要有表示报文类型的字段（例如不能对应答做应答，就要区分应答和数据）。接收方收到的TCP报文，一定会存在不同的类型，针对不同报文类型，接收放要有不同的做法。

6个TCP标志位

ACK：确认号是否有效（标明报文是一个应答报文）acknowledge
SYN：同步标志位，连接建立，握手过程应用的标志位（同步报文段）。

FIN：通知对方，本端要关闭了（结束报文段）。

PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走（psh让系统调用read的条件就绪，比如read本来要500个字节才能解除阻塞，psh允许改。）

关于三次握手：前两次握手不能携带信息，因为第三次握手没有完成！

RST：对方要求重新建立连接（复位报文段）

例如：TCP通信，客户端向服务端发起连接，三次握手后，客户端在发出去请求，收到服务端的捎带应答后，发出应答，不管这个应答有没有丢失，它都认为自己已经建立连接了。对于服务端而言，要晚一步，服务端要收到该应答才能表明建立连接了。如果在该过程中，客户端发送的应答丢失了，客户端还是认为自己建立好了连接，给服务端发送数据，服务端接受到对应的数据就会发送设置好RST的TCP报头，要求客户端重新建立连接。

通信的过程中，连接出现任何问题，都允许进行重置！

否有效就是URG：紧急指针

tcp是保证可靠性的 -> 序号 -> 按序到达的 -> 接收缓冲区 -> 字节流式的接收队列 -> 如果我们有数据，想被优先读取（非主流），优先处理（情况：取消下载，取消上传，需要插队，不要等下载完在取消，效率低）

紧急数据，并不属于常规内容 -> 带外数据。紧急数据，只有一个字节（可用作状态码）。

16位紧急指针含义：当前报文有效载荷中，特定偏移量处，有紧急信息（一个字节）

序列号初步理解

TCP将每个字节的素材都进行了编号，即为序列号。发送缓冲区看成一个字符数组，那么发送缓冲区，每一个字节，天然不就有编号了！

理解丢包，理解应答报文

发送方没有收到ACK，意味着什么？

意味数据包丢失了吗？-> 只能意味着：数据可能丢失，对方可能没收到（例如：信息没丢丢包，ACK丢包了）

否收到消息，无法保证可靠性。就是意味着：要么内容丢，要么应答丢 -> 无法100%保证对方

如何判定是真的丢包了呢？

特定的时间间隔，收不到应答，判定报文丢失！ -> 收不到应答 && 超时

如果数据包没丢失，服务端收到了，但由于应答丢了，客户端超时重传了，此时材料就重复了，怎么解决？

序号的作用：确认应答，按序到达，去重

时间间隔应该是多长？

最理想的情况下，找到一个最小的时间。TCP为了保证无论在任何环境都能比较高性能地通信，因此会动态计算这个最大超时时间。

超时以500ms为一个单位进行控制，重传每次叠加，假设超过一定重传次数，依旧收不到应答，那么TCP认为网络或者对端主机出现异常，强制关闭连接。

连接管理和连接状态

整数，定义的宏值。就是状态就

连接会大量存在，有的刚建立，有的已经释放，要不要管理？要，先描述，在组织struct link。

connect会发起三次握手（cilent），accept不参与三次握手（server），握手工作由OS自动完成。

如何理解accept不参与三次握手？

客户端调用connect向服务端发起连接，不必须服务端进行accept也能完成，并成功与服务端连接。accept只是把OS中已经建立好的连接（struct link）拿上来用了。

为什么建立连接要三次握手？

两个理由：

1）以最小成本，100%确认双方通信意愿

2）以最短的方式，进行验证全双工（本质验证：我们两个所处网络是通畅的，能支持全双工）

如何理解：

2）以cs举例，客户端向服务端发送SYN报头，服务端收到并捎带应答发送SYN+ACK报头，

此时客户端收到了，客户端的发送（ACK报头）和接收（收到SYN+ACK报头）就好了，服务端的接收（SYN报头）也验证了，客户端发送ACK报头，服务器到，服务端的发送能力也验证了（验证了网络通畅和双方都支持全双工）

1）3次握手，是成本最低的，本质也是4次握手，只不过服务端捎带应答（SYN+ACK）

面对客户端的连接请求，服务器都要无脑接受（捎带应答）