传输层TCP跟UDP
为什么我们常用四层网络模型
参考博客
总结上面的博客，ISO七层模型的产生是为了形成标准，但Internet是四层网络。
OSI七层网络模型
五层模型相对七层 ，应用层，表示层，对话层合并为应用层
Interne四层模型
TCP首部详解
TCP首部详解
TCP序列号seq和确认号ack详解
序列号&确认号博客
总结：
1. 序列号 = 上一个包中的确认号
2. 确认号 = 上一个包中序列号+数据长度
对于三次握手的初始确认号和序列号是随机或者指定生成的
初始数据传输时的序列号和确认号和上一个三次握手包中相同
对于存在SYN然后确认好+1是因为SYN占用一位序列号
参考博客2
TCP三次握手，四次结束
三次握手
对于TCP三次握手的描述如下：
1. 客户端A主动向服务器B申请报文，同部位SYN为1，设置序列号为x
2. 服务器如果接受请求，向B发送确认。其中ACK和SYN置为1.设置seq，ack为受到请求包中的seq加1，因为SYN占一位
3. A受到答复后就答复B。ACK置为1，seq为受到包的ack，ack为受到包中seq+1.A此时也会通知上层进程连接已经建立成功。
四次结束
TIME-WAIT的目的是等待2MSL，让本次传输的持续时间内产生的报文都从网络中消失，不会影响下一次的链接。
TCP保证可靠传输（ARQ自动重传请求）
包括：停等协议，回退N帧协议，选择重传协议
停等协议：参考博客
总结参考博客如下：
1》停等协议是发送窗口为1，接收窗口为1的基于链接的ARQ协议。顾名思义发送端发送后就阻塞等待ack然后继续发送。
准备状态
1.初识时发送方处于准备状态，它的初始化s
2.当发送方处于准备状态时，就只是等待应用层的发送请求
3.当受到发送请求的时候，创建分组，保存副本并发送，开启计时器
阻塞状态
当发送方处于阻塞状态时，可能发生一下三件事情
1.接收到无错ack，并且ack==(s+1)%2.那么滑动窗口后移s=（s+1）%2，然后关闭计时器
2.接收到差错ack，或者接受ack不和下一个序列号相关，丢弃ack
3.超时重传，重启计时器
对于接收方来说，不断的接收报文段，分为以下几种情况
1.如果到达分组无差错，seq==R ，那么接收端滑动窗口R=（R+1）%2，发送ack=R
2.如果到达分组被破坏则放弃分组
3.如果到达分组无差错，但是seq！=R，那么丢弃分组，发送ack=R
下面是博客当中的例子，感觉特别好：
2》回退n帧ARQ协议
对于回退N帧的总结如下：
回退N帧是发送窗口为2^m-1,接收窗口为1的ARQ协议。这与停等协议相比，相同的是接收端都是一个窗口，接收一个报文段后返回ack。不同的是发送窗口多余1个时候，将整个数据流分为四部分：已经发送并确认的、已经发送单没收到ack的、窗口内等待发送的、不能发送的。顾名思义如果超时，则重发已经发送但是未被确认的部分，如果ack在Sf和Sn之间，那么标记ack之前为已经确认，滑动窗口右移动，这样也可以保证加入一些ack丢失，当更大序列的ack到达时能够确认ack之前的多个报文段。
发送窗口
如图所示首先将发送端的窗口分为四部分，最左边的是已经发送并确认的、已经发送未被确认、等待发送窗口之内、窗口之外不允许发送的。未来控制滑动窗口（分开这几个区间），设置了Sf来标记第一个待确认的报文段，Sn来标记第一个待发送的报文段，Ssize标记滑动窗口的大小，那么Sf+Ssize不就是第一个滑动窗口之外不允许发送的报文段了吗。博客中把第二段和第三段称之为未完成分组和待发送分组我觉得挺好的。
接收窗口
跟停等协议的一样
发送方
- 等待应用层的发送请求
- 在发送和阻塞的时候如果计时器超时，则重启计时器，重新发送所有未完成分组。（这里准备和阻塞过程中都有可能超时），计时器只有一个的原因是第一个报文先计时，那么它一定先到，所以说用这个就好了
- 创建分组Sn（等待发送的序号），保存副本，发送分组。如果计时器没有运行那么则打开唯一的计时器，如果运行了就继续。Sn = （Sn+1）%2^m,如果窗口满则进入阻塞状态
- 如果无差错ack到达，并且Sf<=ack