传输层协议TCP

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;

• 32位序号/32位确认号

• 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60 • 6位标志位:

◦ URG: 紧急指针是否有效

◦ ACK: 确认号是否有效

◦ PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走

◦ RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段

◦ SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段

◦ FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

• 16位窗口大小: 后面再说

• 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.

• 16位紧急指针: 标识哪部分数据是紧急数据;

• 40字节头部选项: 暂时忽略;

确认序号 = 序号+1

---指定报文序号之前的所有的信息，已经全部收到

另一个核心

下一次发送， 从确认序号开始！

为什么TCP报文里会存在32位序号？

1.支持确认应答

2.解决收报文时的乱序问题

为什么TCP报文里还会存在32位确认序号？

我们未来画图,通信的时候,双方传递的全部都是tcp报文，最少也得是一个报头!

应答是不携带数据的，应答是至少一个报头

为什么要有两个序号？一个序号就可以？

回复对方捎带上自己的数据--捎带应答---抱头+有效载荷！

服务器只做应答吗？不是

捎带应答了

即需要对方报文做确认

自己的报文也有序号！

如果对方接收能力弱了，就减少对方发送速度，甚至不发---流量控制

一台主机接收数据由什么决定---接收缓冲区中剩余空间大小决定】

TCP真实通信时，既采用批量化发送大量数据模式也采用捎带应答机制的，这样效率就拉满了！

正因为有捎带应答机制，任何客户端或服务端给对方发消息既可以对上一次应答做确认又要有自己的序号，所以序号和确认序号必须同时存在。

源端口代表的是对方发送端的应用层进程所绑定的端口号。
目的端口，发送给目标OS的特定绑定的指定端口的进程。
32位序号，32位确认序号是和确认应答机制、按需到达机制、捎带应答机制直接或间接相关的
4位首部长度是为了解决报头和有效载荷分离的，TCP标准报头20个字节，选项部分40个字节的长度

16位窗口大小

对方发送大量数据，缓冲区来不及接收。

再把报文发送过去，被对方直接丢弃掉

浪费，低效

对方接收缓冲区中，剩余空间的大小--数字

发送端如何尽早得知，对方的接受能力呢？

按量按需发送，必须知道对方的接收缓冲区剩余空间的大小

16位窗口大小和流量控制有关

16位窗口大小---缓冲区剩余空间的大小---自己的

我们所构建的报文，都是给对方的

这种按照对面接受能力来动态调整我们发送速度的这种机制叫做流量控制

--合适的流量！发送数据

效率问题

16位校验和，对报文做检测、判断，防止协议在转换中出错

TCP标志位问题

TCP报头本质也是一个个结构体

位段 ---tcp标志位：本质就是报头中的比特位！

为什么要有标志位？

接收方：收到的TCP报文，一定会存在不同的类型，针对不同报文类型，接收方要有不同的做法

要有标识报文类型的字段--标志位

syn标志位

tcp在通信之前要先进行三次握手，才能进行正常通信

SYN---SYN+ACK---ACK

同步标志位：连接建立，握手过程使用的标志位

--表明自己是一个建立连接的报文

其实发送的是报头，只不过tcp报头里对应的标志位置1

前两次握手，不能携带数据，因为三次握手没有完成
只有TCP报头！

客户端给服务器发送报文时，不应该有流量控制吗？那么在第一个发送数据的时候，怎么知道对方缓冲区大小？第一次发送数据，并不是第一次给对方发报文，在通信之前早已经三次握手了。

三次握手，已经可以进行，双方接收能力的协商了！

ACK：确认号是否有效，表明报文是一个应答报文

ACK标志位几乎是被常设为1
应答，应答+数据

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

断开连接 ，进行四次挥手。四次挥手能100%保证对方说的话对方都听到了，本质是两者互相断开连接的请求被对方可靠收到了。

怎么保证是一个断开连接的报文呢？FIN

TCP连接关闭时，四次挥手，FIN

本质是两者断开连接的请求被对方可靠收到了

关闭全双工

FIN：通知对方,本端要关闭了,我们称携带FIN标识的为结束报文段

如果对方来不及把数据取走，那么接收缓冲区数据就会不断变少

PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走

建立连接，一定会成功吗？---不一定
怕的是第三次握手报文ACK丢了，因为没有应答

对于客户端来讲是第三次握手发出ACK就算成功还是客户端知道服务端收到才算成功？

---发出去客户端就认为成功了

客户端跟服务端之间会有时间差

如果丢了，就会造成连接建立是否成功认知不一致

客户端接下来会给服务端发送数据，服务端就可以给客户端发送RST

RST:对方要求重新建立连接,我们把携带RST标识的称为复位报文段

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

URG:紧急指针是否有效

通常要配合16位紧急指针

URG如果置为0 ，表示16位紧急指针无效

URG如果置为1 ，表示16位紧急指针有效

tcp保证可靠性的->序号->按序到达的---接收缓冲区

字节流式的接收队列

如果我们有数据，想被优先读取，优先处理

特殊处理，不是主流

什么情况要优先处理呢？

取消上传

紧急指针+紧急数据---报文数据交互时进行插队

紧急数据，并不属于常规数据

带外数据

MSG_OOB 带外数据

This flag requests receipt of out-of-band data that would not be received in the nor‐

mal data stream.

16位紧急指针---表示当前报文的有效载荷，特定偏移量处，有紧急数据
紧急数据，只有一个字节---状态码

确认应答(ACK)机制

把发送缓冲区，想象成一个char类型的数组

发送缓冲区，每一个字节，天然，不就有编号了吗！

TCP将每个字节的数据都进行了编号.即为序列号.

把发送缓冲区想象成一个char类型的数组 char outbuffer $N$

发送缓冲区，每一个字节，天然，不就有编号了！

每⼀个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发.

超时重传机制

如何理解丢包，重新理解应答报文(正向、反向)

第一种丢包情况

主机A给主机B发消息，包真丢了

• 主机A发送数据给B之后,可能因网络拥堵等原因,数据⽆法到达主机B;

• 如果主机A在⼀个特定时间间隔内没有收到B发来的确认应答,就会进行重发;

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

第二种丢包情况

主机A给主机B发消息，数据收到，但是应答丢了。主机A没收到，就以为丢包了。

因此主机B会收到很多重复数据.那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉.

这时候我们可以利⽤前⾯提到的序列号,就可以很容易做到去重的效果.

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

意味着丢包？--不是，只能意味着：数据可能丢失\对方可能没收到

无法100%保证对方是否收到消息，无法保证可靠性

要么数据丢，要么应答丢

不能确定哪个丢(目前)

只能等待特定的时间间隔，如果在特定的时间间隔内，没有收到应答，判定报文丢失！
---收不到应答 && 超时->丢报了

那时间间隔应该是多长时间？为什么？

应该是变化的，跟网络

那么,如果超时的时间如何确定?

• 最理想的情况下,找到⼀个最小⼩的时间,保证"确认应答⼀定能在这个时间内返回".

• 但是这个时间的⻓短,随着⽹络环境的不同,是有差异的.

• 如果超时时间设的太长,会影响整体的重传效率;

• 如果超时时间设的太短,有可能会频繁发送重复的包;

TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最⼤超时时间.

• Linux中(BSDUnix和Windows也是如此),超时以500ms为⼀个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍.

• 如果重发⼀次之后,仍然得不到应答,等待2*500ms后再进行重传.

• 如果仍然得不到应答,等待4*500ms进行进⾏重传.依次类推,以指数形式递增.

• 累计到⼀定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接.

探索网络的超时时长

再重新发，可能有报文重复问题--序号作用

序号作用：

1.确认应答 2.按序到达 3.去重

连接管理机制

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

内核层面认为状态就是整数宏值
服务器上会存在很多创建好的连接

连接，要不要被管理？

要，先描述再组织！

struct Link

{

......

}

建立连接有成本---时间+空间

connect发起三次握手！----具体过程是由client OS自动完成的

accept，不参与三次握手---具体过程是由server OS自动完成的

例子：男女朋友->夫妻

1.双方愿意

2.父母等外部条件满足

三次握手是什么？
怎么做？
为什么要进行三次握手？

两个理由
1.三次握手是以最短的方式，进行验证全双工！
---本质是验证：我们两个所处的网络是通畅的，能够支持全双工
2.以最小成本,100%确认双方通信意愿

三次握手，真的是三次握手吗？
三次握手本质也是四次握手，把第二步ACK、SYN可以分开

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

服务端状态转化:

• $CLOSED -\> LISTEN$ 服务器端调用listen后进入LISTEN状态, 等待客户端连接;

• $LISTEN -\> SYN_RCVD$ 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.

• $SYN_RCVD -\> ESTABLISHED$ 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.

• $ESTABLISHED -\> CLOSE_WAIT$ 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;

• $CLOSE_WAIT -\> LAST_ACK$ 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)

• $LAST_ACK -\> CLOSED$ 服务器收到了对FIN的ACK, 彻底关闭连接.

客户端状态转化:

• $CLOSED -\> SYN_SENT$ 客户端调用connect, 发送同步报文段;

• $SYN_SENT -\> ESTABLISHED$ connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;

• $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;

• $TIME_WAIT -\> CLOSED$ 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态.

下图是TCP状态转换的一个汇总:

• 较粗的虚线表示服务端的状态变化情况;

• 较粗的实线表示客户端的状态变化情况;

• CLOSED是一个假想的起始点, 不是真实状态;

关于 "半关闭" , 男女朋友分手例子

三次握手：本质不就是,也是建立双方通信的共识吗?本质不就是建立全双工通信!

断开连接的本质：建立双方断开连接的共识。做法：C->S，S->C
C->S,我要发的数据已经发完了，我要和你断开
S->C,我给你发送数据已经发完了，我也要断开连接

4次挥手的过程
以最短次数，建立双方全双工下断开连接的请求

所以linux为了支持对连接进行半关闭

shutdown

NAME

shutdown - shut down part of a full-duplex connnection

SYNOPSIS

#include <sys/socket.h>

int shutdown(int sockfd,int how);

不想给对方发消息了，可以用shutdown

半双工

如果C已经退出，或者关闭。服务器就是不关闭，处于close_wait状态，依旧占用文件fd，连接也没有释放！

fd用完，就必须关掉！---fd泄露问题

一旦一方断开连接，但对方没有发送FIN，对端也就是服务端会一直处于一个close wait的状态。

主动断开连接的一方,要进入一个状态,叫做TIMEWAIT,即便是4次挥手完成
应用角度,既要TIME_WAIT,又要让服务器立即重启!

理解TIME_WAIT状态

• TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态 ,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.

• 我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口;

• MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7/Ubuntu上默认配置的值是60s;

• 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值;

为什么是 TIME_WAIT 的时间是 2MSL ?

• MSL 是 TCP 报文的最大生存时间, 因此 TIME_WAIT 持续存在 2MSL 的话

• 就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);

• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个 FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

目的为了保证历史残留报文，在网络里消散，不要引起下一次通信的错误。

主动断开的一方，肯定是还能接收数据的一方。

为什么主动断开的一方，一旦断开立即重启会绑定失败。

是因为这个连接并没有释放掉，由此想二次启动绑定原始端口就绑定不了。

解决TIME_WAIT状态引起的bind失败的方法

在 server 的 TCP 连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

• 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).

• 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.

• 由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组 (源ip, 源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题.

setsockopt

使用setsockopt()设置socket描述符的选项SO_REUSEADDR为1，

表示允许创建端口号相同，但IP地址不同的多个socket描述符。

理解 CLOSE_WAIT 状态

对于服务器上出现大量的CLOSE_WAIT状态,原因就是服务器没有正确的关闭

socket,导致四次挥手没有正确完成.这是⼀个BUG.只需要加上对应的close即可解决问题.

滑动窗口

确认应答策略,对每⼀个发送的数据段,都要给⼀个ACK确认应答.收到ACK后再发送下

⼀个数据段.这样做有⼀个比较大的缺点,就是性能较差.尤其是数据往返的时间较长的时候.

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

发送方，一次向对方发送多少数据，由什么决定？

滑动窗口决定

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).

• 发送前四个段的时候, 不需要等待任何ACK, 直接发送;

• 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推; • 操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

• 窗口越大, 则网络的吞吐率就越高;

定义两个指针 int start int end

滑动窗口大小=end-start

因为滑动窗口的存在，把发送缓冲区分成三部分

左半部分--已发送已确认 ---- 不就是这部分数据无效了，就是这部分空间可以再被利用了 --- 不需要刻意地清空缓冲区

中间部分--可以直接发，暂时不需要应答

右边部分--待发送

序号在发送的轮次中，数字是依次增大的，也就是也为之滑动窗口未来基本是向右滑动的！(宏观)
---滑动窗口移动的本质，start && end下标增加

滑动窗口的大小，由谁决定?--可以直接发，暂时不要应答
---滑动窗口的大小=对方的接受能力(收到的报文win的大小) $暂时$

滑动窗口的本质：是流量控制的具体实现方案！

start = 报文确认序号

end = start+win(窗口大小)

问题:

1.滑动窗口会向左滑动吗? 不会!
2.滑动窗口,可以变大吗? 可以变小吗?可以不变吗?可以为零吗?

可以动态的
取决于对方的接受能力

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

不会，确认序号的定义决定的!--确认消息一定是连续确认的！---发送必须连续发送--滑动窗口不能跳跃

a.最左侧丢失 ---- 滑动窗口不会向右滑动必须触发重传，确认了才能向右滑动！

1.最左侧报文数据真的丢失了，滑动窗口左侧不变

2.最左侧报文对应的应答丢了，滑动窗口正常工作

如果收到大量一样的ACK，就可以推断这个报文一定丢了---快重传

快重传 vs 超时重传
| |
| 超时 && 没有应答
收到3个同样的确认应答时则进行重发

快重传用来提高效率的
超时重传用来兜底
同时存在，互相配合

tcp发出,暂时没有应答的时候,必须让对应的报文暂时保存起来,以方便后续的重传!

保存到哪里?如何理解保存?

滑动窗口窗口滑动

滑动窗口向右滑就相当于删除了

超时重传和快重传的底层支持是滑动窗口！

b.中间报文丢失

滑动窗口滑动到中间丢失的位置，这样就从中间报文丢失变成最左侧报文丢失

c.最右侧丢失

同理，转化为最左侧丢失

真实情况是这三种情况的组合

滑动窗口不会向右互动必须触发重传,确认了才能向右滑动!

4.滑动窗口,一直向右,会不会溢出?---不会

将该char类型数组当成一个环形

那么如果出现了丢包,如何进行重传?这里分两种情况讨论.

情况⼀:数据包已经抵达,ACK被丢了.

这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进⾏确认;

情况⼆:数据包就直接丢了.

• 当某⼀段报⽂段丢失之后,发送端会⼀直收到1001这样的ACK,就像是在提醒发送端"我想要的是1001" ⼀样;

• 如果发送端主机连续三次收到了同样⼀个"1001"这样的应答,就会将对应的数据1001-2000重新发送;

• 这个时候接收端收到了1001之后,再次返回的ACK就是7001了(因为2001-7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中;

这种机制被称为"高速重发控制"(也叫"快重传").

流量控制

接收端处理数据的速度是有限的.如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等⼀系列连锁反应.

因此TCP支持根据接收端的处理能力,来决定发送端的发送速度.这个机制就叫做流量控制(Flow Control);

• 接收端将自己可以接收的缓冲区剩余空间大小 放入TCP首部中的"窗口大小"字段,通过ACK端通知发送端;

• 窗口大小字段越大,说明网络的吞吐量越高;

• 接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成⼀个更小的值通知给发送端;

• 发送端接受到这个窗口之后,就会减慢自己的发送速度;

• 如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送⼀个窗口探测数据段,使接收端把窗口大小告诉发送端

可不可以在第三次握手的时候，把数据带上--可以

第一、二次不可以

其实我们双方在进行通信之前已经三次握手了，三次握手报文已经交换过了。

前两次三次握手的时候，前两次是不会携带数据的，所以并不存在对方接收不了的问题。

并且前两次我们双方的缓冲区都是空的，也就是说双方在前两次的时候已经互相交换过了各自缓冲区的最大空间。已经得知各自双方的通信能力了。后面再发再更新就能进行正常的流量控制了。

在进行发送时，对方要是来得及接收呢？对方缓冲区如果一下子增大了怎么办？

那么我们就被对方通告给我一个更大的接收窗口。我就可以给对方调整我的滑动窗口，向对方发送更大的数据。所以流量控制不止可以降速也可以增速。

如果主机A给主机B发送消息，但主机B的上层太忙了打满了(没有读)，没时间读取缓冲区，缓冲区剩余空间为0.一旦为0的时候怎么办？

如果对端不发了。想让主机A不能再给主机B发消息。

将滑动窗口设为0，主机A就不再发了

一旦主机A和主机B接收缓冲区为0了，双方怎么知道能继续进行接收呢？

两种做法：

1.主机A周期性地发送窗口探测(其实就是发送一个带序号的TCP报文，不携带数据)，不会放到接收缓冲区里面也就不会丢包，这样主机B就得应答通告自己接收缓冲区剩余大小。

所以主机A定期发送窗口探测为了得到主机B的应答

2.因为TCP通信时，双方是对等的。主机B的窗口大小如果更新了，主机B的OS自动给主机A发送一个窗口更新的通知。在真实的情况下，这两种策略同时被采用，哪一个先到就先采用哪一个。

如果给对方发送消息，对方长时间不更新，连接就自动关了。

接收端如何把窗口大小告诉发送端呢?回忆我们的TCP首部中,有⼀个16位窗口字段,就是存放了窗口大小信息;

那么问题来了,16位数字最大表示65535,那么TCP窗口最大就是65535字节么?

实际上,TCP首部40字节选项中还包含了⼀个窗口扩大因子M,实际窗口大小是窗口字段的值左移M位;

拥塞控制

当前客户端和服务端在通信，客户端发送1000个报文丢了两三个会认为是正常的，客户端直接补发就行了。

但是如果是发送1000个对方只收到了两三个

丢包多，和丢报少结论是不同的

TCP不仅仅考虑了双方主机的问题，还考虑了网络本身的问题！----硬件无障碍的前提!

大面积丢包，我们发送方判定，网络拥塞的问题！
---要不要重发？不能立即重发！

如果立即重发？--增加网络的负载，更加拥堵
如果多个c，多个s，都要走同一个网络！
都会认为网络拥塞！

所以要进行拥塞控制->时刻告诉自己,接下俩我讲的拥塞控制,会让发送端的多个主机,都采用这种策略!

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据.但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.

因为网络上有很多的计算机,可能当前的⽹络状态就已经⽐较拥堵.在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的.

TCP引入 $慢启动$ 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据;

发送数据的方式，重发2^n ---- 慢启动

前期大家都会慢(共识)

一开始主机A认为拥堵了，之后发现网络不拥堵了！---尽快恢复网络通信的过程！

前期是为了探测网络是否恢复，尽快恢复通信过程

初始时期，但是增长速度非常快

不是说好的，发送多少数据，由滑动窗口决定吗？

在我们当前计算机内，衡量网络是否会拥堵的一个指标！ |
滑动窗口->对方的接受能力---为了支持拥塞控制算法->拥塞窗口：一个临界值，值以内，网络较大概率不拥塞，值以外，网络可能拥塞 |
int 拥塞窗口---网络是变化的，就决定这个拥塞窗口一定要进行更新变化！

更正：

滑动窗口 = min(对方win,拥塞窗口) 谁小，谁是主要问题，主要矛盾
既考虑了，网络拥塞问题，又考虑了对方接收能力的问题！

可是，我们总不能一直指数增长吧？我们发送数据的时候，发送数据的量，会进行指数增长吗？不会

拥塞窗口，我们总不能一直指数增长--不是一直指数增长的！

为什么刚刚要指数增长？前期慢，后期快，尽快探测并恢复网络通信

要不要增长？--要不要变化？要变化！

指数增长过渡到线性增长

这个过度点--ssthresh

慢启动--解决拥塞，恢复网络和通信

线性增长部分：本质：不断探测网络的新的拥塞窗口的值！

探测出新的拥塞窗口的值，就可以用该值反向决定自己未来发送的数据

• 此处引入一个概念称为拥塞窗口

• 发送开始的时候, 定义拥塞窗口大小为1;

• 每次收到一个ACK应答, 拥塞窗口加1;

• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增长速度非常快.

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.

• 此处引入一个叫做慢启动的阈值

• 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;

• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;

当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;

拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

拥塞窗口在增加，我发送的数据量一定在增加吗？不一定
1.正常发送数据，基于对方的接受能力进行流量控制->n
2.拥塞窗口的数字，也一直在更新！

加法增大--为了不断探测

衡量网络通畅

在某处拥塞了，探测出来了，当前网络的拥塞窗口

如图发送网络拥塞慢启动又被置为0，

除了支持慢启动，本质，也是重新开始探索网络健康！

下一次从指数到线性的临界点更新--由上次网络拥塞的值/2

不断重复，一直更新

拥塞窗口在线性探测的过程中，会一直增大吗

逻辑上讲，就应该一直增大！

不会一直增大的！有上限

延迟应答---提高效率

等等再应答！在等期间，上层可能从缓冲区拿走一部分数据甚至全拿走

方便上层一起拿走

接收方等待一会，就可能会给发送方，通告一个更大的窗口！

因为给了一个更大的窗口，就有较大概率让发送方更新处一个更大的滑动窗口--可以单次发送更多数据

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;

• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;

• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;

• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

• 数量限制: 每隔N个包就应答一次;

• 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答--提高效率

在延迟应答的基础上,我们发现,很多情况下,客⼾端服务器在应⽤层也是"⼀发⼀收"的.意味着客⼾端

给服务器说了"Howareyou",服务器也会给客⼾端回⼀个"Fine,thankyou";

那么这个时候ACK就可以搭顺风车，和服务器回应的"Fine,thankyou"⼀起回给客户端

面向字节流

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

• 调用write时, 数据会先写入发送缓冲区中;

• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;

• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;

• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;

• 然后应用程序可以调用read从接收缓冲区拿数据;

• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工

由于缓冲区的存在, TCP程序的读和写不需要一一匹配,

例如:

• 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;

• 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

粘包问题

$八戒吃馒头例子$ |

• 首先要明确, 粘包问题中的 "包" , 是指的应用层的数据包.

• 在TCP的协议头中, 没有如同UDP一样的 "报文长度" 这样的字段, 但是有一个序号这样的字段.

• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中. •

站在应用层的角度, 看到的只是一串连续的字节数据.

• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;

• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;

• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

解决粘包问题--明确报文和报文之间的边界---协议+序列和反序列化

思考: 对于UDP协议来说, 是否也存在 "粘包问题" 呢?

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.

• 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况.

TCP异常情况

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

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

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

另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

进程退出，进程打开的文件不在！

关机之前，操作系统要关闭所有进程！

连接的保活---tcp自带，大几十分钟级别的。

保活机制，都是应用层自己完成的！
echo server

总是会被正常释放掉---TCP对于异常连接，有很强的容错处理！

TCP小结

为什么TCP这么复杂?因为要保证可靠性,同时⼜尽可能的提高性能.

可靠性:

• 校验和

• 序列号(按序到达)

• 确认应答

• 超时重发

• 连接管理

• 流量控制

• 拥塞控制

提高性能:

• 滑动窗口

• 快速重传

• 延迟应答

• 捎带应答

其他:

• 定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等)

基于TCP应用层协议

• HTTP

• HTTPS

• SSH

• Telnet

• FTP

• SMTP

当然,也包括你自己写TCP程序时自定义的应用层协议;

TCP/UDP对比

我们说了TCP是可靠连接,那么是不是TCP⼀定就优于UDP呢?TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较

• TCP用于可靠传输的情况,应用于文件传输,重要状态更新等场景;

• UDP用于对高速传输和实时性要求较高的通信领域,例如,早期的QQ,视频传输等.另外UDP可以用于广播;

归根结底,TCP和UDP都是程序员的工具,什么时机用,具体怎么用,还是要根据具体的需求场景去判定.

⽤UDP实现可靠传输(经典面试题)

参考TCP的可靠性机制,在应用层实现类似的逻辑;

例如:

• 引⼊序列号,保证数据顺序;

• 引⼊确认应答,确保对端收到了数据;

• 引⼊超时重传,如果隔⼀段时间没有应答,就重发数据;

...

接收和发送队列

进程所对应的文件描述符表指向自己的文件，如果这个文件打开是套接字会指向一个struct socket对象

而struct socket对象里面会有一个回指指针struct file

private_data指向struct socket ,struct file回指指向struct file

这样文件部分跟网络部分就关联起来了。

这样就可以继续保证一切皆文件

如果有进程读写网络套接字，但是这个网络套接字里面没有数据。就可以把指定进程的PCD放入到该套接字对应的等待队列中。

上图就是接收队列和发送队列

之前说的TCP的接收跟发送缓冲区就是他

inet_sock里面包含一个sock对象

当底层建立好一次连接时，底层OS会给我们做什么？

当我们建立连接成功，OS内核只需要给我创建一个TCPsocket结构就可以了

将图中上面那个指针强转成对应类型

实现了C语言版本的多态机制！

UDP也一样，只不过UDP套接字里面是inet_socket

而inet_sock包含了我们的sock

socket里面包含了接收和发送队列。

UDP没有TCP 的 struct inet_connecction sock，连接相关的东西。

感谢你的观看，期待我们下次再见！