传输层协议UDP,TCP

目录

1.传输层

[1.1 端口号](#1.1 端口号)

[2. UDP协议](#2. UDP协议)

[2.1 UDP协议段格式](#2.1 UDP协议段格式)

​编辑

[2.2 UDP的特点](#2.2 UDP的特点)

[2.3 UDP使⽤注意事项及基于UDP的应⽤层协议](#2.3 UDP使⽤注意事项及基于UDP的应⽤层协议)

3.TCP协议

[3.1 TCP协议段格式](#3.1 TCP协议段格式)

[3.1.1 基础字段](#3.1.1 基础字段)

[3.1.2 确认应答(ACK)机制，序号及确认序号字段](#3.1.2 确认应答(ACK)机制，序号及确认序号字段)

[3.1.3 流量控制，16位窗口字段](#3.1.3 流量控制，16位窗口字段)

[3.1.4 6个标志位及紧急指针](#3.1.4 6个标志位及紧急指针)

[3.2 超时重传机制](#3.2 超时重传机制)

[3.3 连接管理机制](#3.3 连接管理机制)

[​编辑3.3.1 三次握⼿](#编辑3.3.1 三次握⼿)

[3.3.2 四次挥⼿](#3.3.2 四次挥⼿)

[3.3.3 TIME_WAIT状态引起的bind失败的⽅法](#3.3.3 TIME_WAIT状态引起的bind失败的⽅法)

[3.3.4 CLOSE_WAIT 状态](#3.3.4 CLOSE_WAIT 状态)

[3.4 滑动窗⼝](#3.4 滑动窗⼝)

[3.4.1 概念](#3.4.1 概念)

[3.4.2 关于滑动窗口的几个问题](#3.4.2 关于滑动窗口的几个问题)

[3.5 拥塞控制](#3.5 拥塞控制)

[3.6 延迟应答](#3.6 延迟应答)

[3.7 ⾯向字节流](#3.7 ⾯向字节流)

[3.8 粘包问题](#3.8 粘包问题)

[3.9 TCP异常情况及基于TCP应⽤层协议](#3.9 TCP异常情况及基于TCP应⽤层协议)

4.TCP/UDP对⽐

[5. 报文](#5. 报文)

---

1.传输层

传输层 :负责数据能够从发送端传输接收端

1.1 端口号

端⼝号(Port)标识了⼀个主机上进⾏通信的不同的应⽤程序

在TCP/IP协议中, ⽤ "源IP", "源端⼝号", "⽬的IP", "⽬的端⼝号", "协议号" 这样⼀个五元组来标识⼀个通信(Liunx可以通过netstat -n查看);

端⼝号范围划分

0 - 1023: 知名端⼝号, HTTP, FTP, SSH等这些⼴为使⽤的应⽤层协议, 这些的端⼝号都是固定的.
ssh服务器, 使⽤22端⼝
ftp服务器, 使⽤21端⼝
telnet服务器, 使⽤23端⼝
http服务器, 使⽤80端⼝
https服务器, 使⽤443端口
Liunx中使用 cat /etc/services命令， 可以看到知名端⼝号
1024 - 65535: 操作系统动态分配的端⼝号. 客⼾端程序的端⼝号, 就是由操作系统从这个范围分配的.
注意：
写⼀个程序使⽤端⼝号时, 要避开这些知名端⼝号
⼀个进程可以bind多个端⼝号，⼀个端⼝号不能可以被多个进程bind

2. UDP协议

2.1 UDP协议段格式

16位UDP⻓度, 表⽰整个数据报(UDP⾸部+UDP数据)的最⼤⻓度;
如果校验和出错, 就会直接丢弃

由于UDP的报头是固定8字节的，因此需要进行有效载荷与报头分离都是固定的，只需要剔除前8字节，之后交付上层就行了

协议本质是结构体，OS之间，可以之间传递结构体对象

struct udphdr {
    u_int16_t source; // 源端口号
    u_int16_t dest; // 目的端口号
    u_int16_t len; // UDP 数据包的长度（包括头部和数据）
    u_int16_t check; // 校验和
};

2.2 UDP的特点

UDP传输的过程类似于寄信.

⽆连接: 知道对端的IP和端⼝号就直接进⾏传输, 不需要建⽴连接;
不可靠: 没有确认机制, 没有重传机制; 如果因为⽹络故障该段⽆法发到对⽅, UDP协议层也不会给应⽤层返回任何错误信息;
⾯向数据报: 不能够灵活的控制读写数据的次数和数量;
面向数据报解释如下：
应⽤层交给UDP多⻓的报⽂, UDP原样发送, 既不会拆分, 也不会合并;
⽤UDP传输100个字节的数据:
如果发送端调⽤⼀次sendto, 发送100个字节, 那么接收端也必须调⽤对应的⼀次recvfrom, 接收100个字节; ⽽不能循环调⽤10次recvfrom, 每次接收10个字节;
UDP的缓冲区
UDP没有真正意义上的 发送缓冲区. 调⽤sendto会直接交给内核, 由内核将数据传给⽹络层协议进⾏后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序⼀致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
UDP的socket既能读, 也能写, 这个概念叫做 全双⼯

2.3 UDP使⽤注意事项及基于UDP的应⽤层协议

UDP协议⾸部中有⼀个16位的最⼤⻓度. 也就是说⼀个UDP能传输的数据最⼤⻓度是
64K(包含UDP⾸部).
然⽽64K在当今的互联⽹环境下, 是⼀个⾮常⼩的数字，如果需要传输的数据超过64K, 就需要在应⽤层⼿动的分包, 多次发送, 并在接收端⼿动拼装;
基于UDP的应⽤层协议
NFS: ⽹络⽂件系统
TFTP: 简单⽂件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(⽤于⽆盘设备启动)
DNS: 域名解析协议
当然, 也包括用户⾃⼰写UDP程序时⾃定义的应⽤层协议;

3.TCP协议

TCP 全称为 "传输控制协议( Transmission Control Protocol ").要对数据的传输进⾏⼀个详细的控制;

3.1 TCP协议段格式

和UDP类似TCP的报头除选项字段外固定长度为20字节

接下来看每个字段

3.1.1 基础字段

源/⽬的端⼝号: 表⽰数据是从哪个进程来, 到哪个进程去;
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP⾸部, 也包含TCP数据部分.

下面详细先说明一下4位首部长度，以及选项字段

这个4位首部长度代表⽰该TCP头部有多少个32位bit(有多少个4字节)，由于选项字段前固定为220字节，因此可以根据首部长度来退出，选项字段的大小，在二进制中4位最大为1111，代表15，协议规定：基本单位为4字节，因此，TCP的报文长度就在[20,60]字节

因此要使TCP协议报头和有效载荷分离，首先剔除20字节，找到4位首部长度，推出选项字段大小，之后进行分离就行了

3.1.2 确认应答(ACK)机制，序号及确认序号字段

TCP由于是具有可靠性的，那怎么保证可靠？

当有应答就行（类似与日常和其他人聊天是，如何保证对方看见了，对方回答这条信息就代表可靠），但是最新的报文，永远没有应答，因此最新可靠性无法保证，可以保证历史消息可靠，这就是确认应答(ACK)机制

TCP将每个字节的数据都进⾏了编号. 即为序列号（TCP协议段字段）

每⼀个ACK都带有对应的确认序列号（确认序列号=序列号+1）, 意思是告诉发送者, 收到了哪些数据，下⼀次发送从确认序号开始
那为什么会有两个序号，一个序号不就可以了吗？
举个例子，A对B说：你今天吃了啥，B对A说：吃了番茄炒鸡蛋......

这里就能看出，当双方通信时，不仅要对对方进行应答，还要有数据携带，而这就是捎带应答，而捎带应答就包含了报头和有效载荷，即需要对对方报文确认，而自己的报文也有序号，此时就需要两个序号

3.1.3 流量控制，16位窗口字段

在TCP传输中，发送端有接受缓冲区，接受端有接受缓冲区，接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继⽽引起丢包重传等等⼀系列连锁反应、因此TCP⽀持根据接收端的处理能⼒, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

接收端将⾃⼰可以接收的缓冲区剩余空间⼤⼩放⼊TCP ⾸部中的 "窗⼝⼤⼩" 字段, 通过ACK端通知发送端;
窗⼝⼤⼩字段越⼤, 说明⽹络的吞吐量越⾼;
接收端⼀旦发现⾃⼰的缓冲区快满了, 就会将窗⼝⼤⼩设置成⼀个更⼩的值通知给发送端;
发送端接受到这个窗⼝之后, 就会减慢⾃⼰的发送速度;
如果接收端缓冲区满了, 就会将窗⼝置为0; 这时发送⽅不再发送数据, 但是需要定期发送⼀个窗⼝探测数据段, 使接收端把窗⼝⼤⼩告诉发送端.
实际上, TCP⾸部40字节选项中还包含了⼀个窗⼝扩⼤因⼦M, 实际窗⼝⼤⼩是窗⼝字段的值左移 M 位

3.1.4 6个标志位及紧急指针

标志位本质就是报头中的比特位，为什么需要标志位，这是由于接受方在组织收到TCP报文是，有的报文是请求连接，有的是断开连接，因此针对不同的报文类型，接受方需要不同的做法，因此就要有表示报文类型的字段

在TCP字段中，还有6个标志位，分别是URG，ACK，PSH，RST，SYN，FIN

SYN: 请求建⽴连接; 把携带SYN标识的称为同步报⽂段

FIN: 通知对⽅, 本端要关闭了, 携带FIN标识的为结束报⽂段
RST: 对⽅要求重新建⽴连接; 携带RST标识的称为复位报⽂段，通信过程中，连接出现问题，都可以进行重置
ACK: 确认序号是否有效，一般情况下这个标志位常被设为1，表示应答，应答+数据
PSH: 提⽰接收端应⽤程序⽴刻从TCP缓冲区把数据读⾛，在上文了解流量控制，当接收端缓冲区数据快满了，发送端为了提升发送效率，就会设置这个标志位进行提示，不过也只能起到提示的作用，如何读取，什么时间读取，由上层决定
URG: 紧急指针是否有效

接下来叙述紧急指针的内容

TCP由于为了保证可靠性，对数据进行了序号的排列，在接受缓冲区中，字节流式的结束队列，如果有数据想要优先读取（eg:取消上传），就需要紧急指针，注意紧急指针只能在特定情况用

而URG表示紧急指针是否有效，TCP的数据是有序号的（理解为一个长的字符数组），因此为了判断紧急数据位置，16位紧急指针代表偏移量，注意紧急数据只有一个字节

3.2 超时重传机制

主机A发送数据给B之后, 可能因为⽹络拥堵等原因, 数据⽆法到达主机B;
如果主机A在⼀个特定时间间隔内没有收到B发来的确认应答, 就会进⾏重发;

但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了;

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候可以利⽤前⾯提到的序列号, 就可以很容易做到去重的效果.
注意：当发送端没有收到应答ACK，并不代表丢包，只能意味着数据可能丢失或者对方可能没有收到，只有当特定的时间间隔收不到应答时，才能判断报文丢失，因此丢包有两个条件：收不到应答&&超时
那么, 如果超时的时间如何确定?
最理想的情况下, 找到⼀个最⼩的时间, 保证 "确认应答⼀定能在这个时间内返回".
但是这个时间的⻓短, 随着⽹络环境的不同, 是有差异的.
如果超时时间设的太⻓, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包;
TCP为了保证⽆论在任何环境下都能⽐较⾼性能的通信, 因此会动态计算这个最⼤超时时间.
Linux中(BSD Unix和Windows也是如此), 超时以500ms为⼀个单位进⾏控制, 每次判定超时重发
的超时时间都是500ms的整数倍.
如果重发⼀次之后, 仍然得不到应答, 等待 2*500ms 后再进⾏重传.
如果仍然得不到应答, 等待 4*500ms 进⾏重传. 依次类推, 以指数形式递增.
累计到⼀定的重传次数, TCP认为⽹络或者对端主机出现异常, 强制关闭连接.

3.3 连接管理机制

在正常情况下, TCP要经过三次握⼿建⽴连接, 四次挥⼿断开连接

3.3.1 三次握⼿

在建立连接过程中，连接同样也要被进行管理，由于建立连接有成本

connect发起三次握手，但是这内部握手的过程则是有客户端OS自动完成的，accept不参与三次握手，由服务端OS自动完成

为什么需要三次握手，举个例子男女双方结婚，需要两个条件：1.双方愿意 2.父母等外部因素

这就说明需要以最小的成本，确认双方通信的意愿

以最短的方式，进行验证全双工，本质验证双方所处的网络是通畅的，能够支持全双工

这里还有个细节

其实三次握手本质是四次握手，但是服务端给客户端应答ACK时，捎带了SYN

其次来看看相应的状态变化
服务端状态转化:

CLOSED -\> LISTEN\] 服务器端调⽤listen后进⼊LISTEN状态, 等待客⼾端连接; \[LISTEN -\> SYN_RCVD\] ⼀旦监听到连接请求(同步报⽂段), 就将该连接放⼊内核等待队列中, 并向客⼾端发送SYN确认报⽂.

客⼾端状态转化:

CLOSED -\> SYN_SENT\] 客⼾端调⽤connect, 发送同步报⽂段; \[SYN_SENT -\> ESTABLISHED\] connect调⽤成功, 则进⼊ESTABLISHED状态, 开始读写数据;

3.3.2 四次挥⼿

在断开连接的过程中，需要进行四次挥手，客户端向服务端断开连接，服务端向客户端断开连接

断开连接的本质：建立双方断开连接的共识

接下看这四次挥手的状态变化
服务端状态转化:

ESTABLISHED -\> CLOSE_WAIT\] 当客⼾端主动关闭连接(调⽤close), 服务器会收到结束报⽂段, 服务器返回确认报⽂段并进⼊CLOSE_WAIT; \[CLOSE_WAIT -\> LAST_ACK\] 进⼊CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调⽤close关闭连接时, 会向客⼾端发送FIN, 此时服务器进⼊LAST_ACK状态, 等待最后⼀个ACK到来(这个ACK是客⼾端确认收到了FIN)

客⼾端状态转化:

ESTABLISHED -\> FIN_WAIT_1\] 客⼾端主动调⽤close时, 向服务器发送结束报⽂段, 同时进⼊FIN_WAIT_1; \[FIN_WAIT_1 -\> FIN_WAIT_2\] 客⼾端收到服务器对结束报⽂段的确认, 则进⼊FIN_WAIT_2, 开始等待服务器的结束报⽂段; \[FIN_WAIT_2 -\> TIME_WAIT\] 客⼾端收到服务器发来的结束报⽂段, 进⼊TIME_WAIT, 并发出LAST_ACK;

那断开连接为什么不能向三次握手一样，把ACK和FIN携带？

这是由于报文在传递过程中，可能会超时，但是这个报文可能还会在网络中存活着，当客户端断开连接后，再立即重启时，在建立连接时，这个残存的报文可能就会到来，可能就会影响下次连接的过程，因此
TCP协议规定,主动关闭连接的⼀⽅要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
为什么是 TIME_WAIT 的时间是 2MSL ?

MSL 是 TCP 报⽂的最⼤⽣存时间, 因此 TIME_WAIT 持续存在 2MSL 的话
就能保证在两个传输⽅向上的尚未被接收或迟到的报⽂段都已经消失(否则服务器⽴刻重启, 可能会收到来⾃上⼀个进程的迟到的数据, 但是这种数据很可能是错误的);
同时也是在理论上保证最后⼀个报⽂可靠到达(假设最后⼀个ACK丢失, 那么服务器会再重发⼀个FIN. 这时虽然客⼾端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

3.3.3 TIME_WAIT状态引起的bind失败的⽅法

⾸先启动server,然后启动client,然后⽤Ctrl-C使server终⽌,这时⻢上再运⾏server, 结果会导致服务器bind失败

这是因为,虽然server的应⽤程序终⽌了,但TCP协议层的连接并没有完全断开,因此不能再次监 听同样的server端⼝
服务器需要处理⾮常⼤量的客⼾端的连接(每个连接的⽣存时间可能很短, 但是每秒都有很⼤数量的客⼾端来请求).
这个时候如果由服务器端主动关闭连接(⽐如某些客⼾端不活跃, 就需要被服务器端主动清理掉),就会产⽣⼤量TIME_WAIT连接.
由于请求量很⼤, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占⽤⼀个通信五元组
(源ip, 源端⼝, ⽬的ip, ⽬的端⼝, 协议). 其中服务器的ip和端⼝和协议是固定的. 如果新来的客⼾端连接的ip和端⼝号和TIME_WAIT占⽤的链接重复了, 就会出现问题

可以使⽤ setsockopt ()设置 socket 描述符的 选项 SO_REUSEADDR 为 1 , 表⽰允许创建端⼝号相同但IP地址不同的多个 socket 描述符

3.3.4 CLOSE_WAIT 状态

对于服务器上出现⼤量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭socket , 导致四次挥⼿没有正确完成. 这是⼀个 BUG . 只需要加上对应的 close 即可解决问题.
注意：如果客户端已经退出，服务端就是不关闭，处于CLOSE_WAIT 状态,依旧会占有文件描述符fd，连接没有释放就会有文件描述符溢出问题

3.4 滑动窗⼝

3.4.1 概念

上文中确认应答策略, 对每⼀个发送的数据段, 都要给⼀个ACK确认应答. 收到ACK后再发送下
⼀个数据段. 这样做有⼀个⽐较⼤的缺点, 就是性能较差. 尤其是数据往返的时间较⻓的时候.

既然这样⼀发⼀收的⽅式性能较低, 那么⼀次发送多条数据, 就可以⼤大的提⾼性能(其实是将多个段的等待时间重叠在⼀起了).

发送方一次向对方发多少数据由滑动窗口决定
窗⼝⼤⼩指的是⽆需等待确认应答⽽可以继续发送数据的最⼤值. 上图的窗⼝⼤⼩就是4000个字节(四个段).
发送前四个段的时候, 不需要等待任何ACK, 直接发送;
收到第⼀个ACK后, 滑动窗⼝向后移动, 继续发送第五个段的数据，依次类推;
操作系统内核为了维护这个滑动窗⼝, 需要开辟发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
窗⼝越⼤, 则⽹络的吞吐率就越⾼;
滑动窗口的本质其实就是流量控制的具体实验方案

3.4.2 关于滑动窗口的几个问题

滑动窗口能够向左移动吗？

滑动窗口其实是发送缓冲区的一部分，发送缓冲区在逻辑上可以用一个长一维数组表示，而滑动窗口的东西可以利用两个指针来表示，在数据发送途中，滑动窗口的左边数据是已确认发送的，同时序号在发生的轮次中也是依次增大，也就意味着滑动窗口基本是向右滑动的

滑动窗口的本质，就是两个下标增加

滑动窗口的大小是否可以变换？

可以变化，这是因为滑动窗口的大小有对方的接受能力来判断的，若对方接受能力小，窗口就会相应变小，反之亦然

滑动窗口如果丢包了怎么办？会不会跳过报文进行应答？

首先滑动窗口不会跳过报文进行应答，这是由于确认序号的存在，确认消息一定是连续的，发送必须连续，因此不能跳跃

丢包的情况分为三种：a.最左侧丢包，b.中间丢包，c.最右侧丢包

首先来看a情况，当最左侧丢包时，滑动窗口不会向右移动，必须触发重传，确认了才能向右移动

1.当数据已经传过去，应答丢失了

这种情况下, 部分ACK丢了并不要紧, 因为可以通过确认序号以及后续的ACK进⾏确认;
当应答丢失，滑动窗口正常工作
2. 数据直接丢了

当某⼀段报⽂段丢失之后, 发送端会⼀直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是1001" ⼀样;
如果发送端主机连续三次收到了同样⼀个 "1001" 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为 "⾼速重发控制"(也叫 "快重传")
当最左侧的报文数据丢了，滑动窗口，左侧不变，当中间报文和最右侧报文丢失，滑动窗口左侧没问题会向右移动，此时不管中间报文和最右侧报文丢失，都会转化为最左侧报文丢失

3.5 拥塞控制

在上文讲述的方法中，都是两台主机，没有考虑中间方（网络）的情况，虽然TCP有了滑动窗⼝这个⼤杀器, 能够⾼效可靠的发送⼤量的数据. 但是如果在刚开始阶段就发送⼤量的数据, 仍然可能引发问题.因为⽹络上有很多的计算机, 可能当前的⽹络状态就已经⽐较拥堵. 在不清楚当前⽹络状态下, 贸然发送⼤量的数据, 是很有可能引起雪上加霜的
因此TCP不仅仅考虑了双方主机的问题，在网络硬件无障碍的前提下，还考虑了网络本身的问题，当客户端向服务端发送大量报文是，若丢包少重发就可以了，若丢包多，则会判定是网络拥塞的问题，此时就不能立即重发，为了解决这种问题，TCP引⼊慢启动机制
慢启动： 先发少量的数据, 探探路, 摸清当前的⽹络拥堵状态, 再决定按照多⼤的速度传输数据;发送数据为2^n

此处引⼊⼀个概念称为拥塞窗⼝，发送开始的时候, 定义拥塞窗⼝⼤⼩为1
每次收到⼀个ACK应答, 拥塞窗⼝加1;
每次发送数据包的时候, 将拥塞窗⼝和滑动窗口大小做⽐较, 取较⼩的值作为实际发送的窗⼝;

像上⾯这样的拥塞窗⼝增⻓速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增⻓速度⾮常快. 为了不增⻓的那么快, 因此不能使拥塞窗⼝单纯的加倍. 此时就会有慢启动的阈值，当拥塞窗⼝超过这个阈值的时候, 不再按照指数⽅式增⻓, ⽽是按照线性⽅式增⻓，如下图

当TCP开始启动的时候, 慢启动阈值等于窗⼝最⼤值;
在 拥塞窗⼝指数增长，其实就是在尽快恢复网络通信的过程，在线性增长时不会一直增大
拥塞窗口在增加，发送的数据量不一定在增加，还要根据对方的接受能力进行流量控制
在每次超时重发的时候, 慢启动阈值会变成原来的⼀半, 同时拥塞窗⼝置回1;

当TCP通信开始后, ⽹络吞吐量会逐渐上升; 随着⽹络发⽣拥堵, 吞吐量会⽴刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对⽅, 但是⼜要避免给⽹络造成太⼤压⼒的折中⽅案

3.6 延迟应答

如果接收数据的主机⽴刻返回ACK应答, 这时候返回的窗⼝可能⽐较⼩.
假设接收端缓冲区为1M. ⼀次收到了500K的数据; 如果⽴刻应答, 返回的窗⼝就是500K; 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了; 在这种情况下, 接收端处理还远没有达到⾃⼰的极限, 即使窗⼝再放⼤⼀些, 也能处理过来; 如果接收端稍微等⼀会再应答, ⽐如等待200ms再应答, 那么这个时候返回的窗⼝⼤⼩就是1M;
窗⼝越⼤, ⽹络吞吐量就越⼤, 传输效率就越⾼. 在保证⽹络不拥塞的情况下尽量提⾼传输效率;
那么所有的包都可以延迟应答么? 肯定也不是;

数量限制: 每隔N个包就应答⼀次;
时间限制: 超过最⼤延迟时间就应答⼀次;
具体的数量和超时时间, 依操作系统不同也有差异; ⼀般N取2, 超时时间取200ms;

3.7 面向字节流

创建⼀个TCP的socket, 同时在内核中创建⼀个 发送缓冲区 和⼀个接收缓冲区;

调⽤write时, 数据会先写⼊发送缓冲区中; 如果发送的字节数太⻓, 会被拆分成多个TCP的数据包发出; 如果发送的字节数太短, 就会先在缓冲区⾥等待, 等到缓冲区⻓度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从⽹卡驱动程序到达内核的接收缓冲区; 然后应⽤程序可以调⽤read从接收缓冲区拿数据;
另⼀⽅⾯, TCP的⼀个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这⼀个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双⼯
由于缓冲区的存在, TCP程序的读和写不需要⼀ 匹配, 例如:
写100个字节数据时, 可以调⽤⼀次write写100个字节, 也可以调⽤100次write, 每次写⼀个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以⼀次read 100个字节, 也可以⼀次read⼀个字节, 重复100次;

3.8 粘包问题

⾸先要明确, 粘包问题中的 "包" , 是指的应⽤层的数据包，在TCP的协议头中, 没有如同UDP⼀样的 "报⽂⻓度" 这样的字段, 但是有⼀个序号这样的字段，站在传输层的⻆度, TCP是⼀个⼀个报⽂过来的. 按照序号排好序放在缓冲区中，站在应⽤层的⻆度, 看到的只是⼀串连续的字节数据，那么应⽤程序看到了这么⼀连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是⼀个完整的应⽤层数据包.
那么如何避免粘包问题呢? 明确两个包之间的边界.

对于定⻓的包, 保证每次都按固定⼤⼩读取即可; 例如上⾯的Request结构, 是固定⼤⼩的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
对于变⻓的包, 可以在包头的位置, 约定⼀个包总⻓度的字段, 从⽽就知道了包的结束位置;
还可以在包和包之间使⽤明确的分隔符(应⽤层协议, 是程序猿⾃⼰来定的, 只要保证分隔符不和正⽂冲突即可);

3.9 TCP异常情况及基于TCP应⽤层协议

进程终⽌: 进程终⽌会释放⽂件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.

机器重启: 和进程终⽌的情况相同.

机器掉电/⽹线断开: 接收端认为连接还在, ⼀旦接收端有写⼊操作, 接收端发现连接已经不在了, 就会进⾏reset. 即使没有写⼊操作, TCP⾃⼰也内置了⼀个保活定时器, 会定期询问对⽅是否还在. 如果对⽅不在, 也会把连接释放.

另外, 应⽤层的某些协议, 也有⼀些这样的检测机制. 例如HTTP⻓连接中, 也会定期检测对⽅的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.
基于TCP应⽤层协议（了解）

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

4.TCP/UDP对⽐

TCP是可靠连接, 那么是不是TCP⼀定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单,
绝对的进⾏⽐较

TCP⽤于可靠传输的情况, 应⽤于⽂件传输, 重要状态更新等场景;
UDP⽤于对⾼速传输和实时性要求较⾼的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以⽤于⼴播;
⽤UDP实现可靠传输
参考TCP的可靠性机制, 在应⽤层实现类似的逻辑;
例如:
引⼊序列号, 保证数据顺序;
引⼊确认应答, 确保对端收到了数据;
引⼊超时重传, 如果隔⼀段时间没有应答, 就重发数据;
..........

5. 报文

报文=报头+有效载荷

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

这是由于不同层之间一般都是解耦的，由于进行报文的解析处理CPU触发时钟中断，OS从网络中读取报文同时也会进行外部的硬件中断，因此两者互不干扰

在OS中，一定会同时存在大量的报文，而这些报文，OS必须要进行管理（先描述，在组织），在OS中管理报文的结构体是sk_buff

struct sk_buff {
struct sk_buff *next; // 链表中的下一个节点
struct sk_buff *prev; // 链表中的上一个节点

struct sock *sock; // 关联的 socket 信息
unsigned int len; // 数据包的总长度
unsigned int data_len; // 非线性数据的长度

char *data; // 数据区的起始位置
char *head; // 缓冲区的起始位置
char *tail; // 数据区的结束位置
char *end; // 缓冲区的结束位置

struct net_device *dev; // 关联的网络设备
__u8 pkt_type; // 数据包类型（单播、广播等）
atomic_t users; // 引用计数
};

发现sk_buff中有四个指针，如下图

因此当需要增加协议报头和分离是，本质就是移动data指针在缓冲区中的指向位置，当data指针每次+-时就代表对应层的协议长度