运输层
就俩协议，TCP，UDP，TCP需要建立连接，UDP不需要。
UDP首部只有8个字节，TCP首部20个字节。IPv6有40个字节好像。
源端口目的端口长度检验和各占2字节
注意这个伪首部是用来检验和的，既不向下传送也不向上递交，仅仅为了计算检验和。
讲讲TCP，难得一匹
把不可靠的传输信道转换为可靠的传输信道
停止等待协议
每发送一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组
如果超过一段时间没有收到确认，就重新发送，叫超时重传，设一个超时重传器
自动重传请求ARQ
但是信道利用率太低，用连续ARQ协议和滑动窗口协议。是TCP的精髓所在。
每收到一个确认，就向前滑动一下，接收方一般会累积，不会对收到的分组都发送确认，缺点是容易出现回退，如果中间出现缺失，而其他的没事，那么仍然缺失后的都要重传。
这样呢，出现选择确认SACK，就是即便不连续，也可以的，但是现在并不怎么支持。
如果发送数据太快，接收方来不及接收呢？这样效率实际上也是下降的，因此出现了流量控制：接收方每次都回送一个窗口，告诉发送者能发送多少。这里有一个死锁，如果发回一个0窗口，发送方就不动了，然后接收方发回多窗口但失败了，发送方就仍不动，这种死锁会一直延续下去，解决办法就是设一个持续计时器，发送方在等到计时器结束还没有接收到扩展窗口报文，就发送一个零窗口探测报文，然后就会返回确认报文。
如何控制TCP发送报文的时机仍然是一个复杂的问题。
网络超负荷后，就会拥塞，因此需要拥塞控制处理，进行拥塞控制是需要代价的，分为开环控制和闭环控制，开环控制就是在设计网络时事先考虑周到，一旦运行起来就不中途修正了。闭环控制基于反馈环路概念，检测拥塞的所有属性。
进行拥塞控制的算法有四种，慢开始，拥塞避免，快重传，快恢复
慢开始：有一个拥塞窗口，发送方让自己的发送窗口等于拥塞窗口，当网络良好时，逐渐增大拥塞窗口，慢开始是因为并不清楚网络的负荷情况，就由小到大逐渐增大发送窗口。每经过一个传输轮次，拥塞窗口cwnd就加倍。
为了防止慢开始增长过大，就需要拥塞避免算法，拥塞避免算法是线性的，不是加倍增长
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失，它会立即发送确认，失序报文段仍要发送确认，但是是正常收到的那一串报文最后那个报文的确认，发送方只要一连收到3个重复确认，就知道哪个报文段缺失了，因此应当立即进行重传，这就是快重传。使用快重传可以使整个网络的吞吐量提高20%。
发送方知道现在只是丢失了个别的报文段，就开始执行快恢复：调整门限值，同时设置拥塞窗口。
全局同步现象：一旦一个路由超负荷，开始丢包，丢包的主机就会进入慢开始状态，并且是很多主机同时进入这种状态，等好了又同时网速突然增大。
主动队列管理AQM：等队列长度达到某个数值就主动放弃分组，一般是随机丢弃
TCP运输连接管理
大名鼎鼎的三次握手
B先创建传输控制块
A创建传输控制块，需要的时候才创建
然后A发送一个请求
B发回一个确认
A给B一个确认，这主要是为了防止已经失效的连接请求报文突然又传送到B，尤其是连接建立运输完失效后，再来，以为是新连接，这就不行了，只要B发出确认，连接就建立了，B白白等着A，这不行。
如果B只等A的确认报文呢？因为这时候并没有建立连接，因此不会浪费资源。
TCP连接释放
首先是A先发送中止报文，
B发回确认，此时A已经没有数据要发送了，但B要发送数据，A仍要接收。
A收到确认后，还要继续监听B的中止报文
B发送释放报文
A发回确认，同时进入计时状态，然后关闭，因为如果A的确认报文丢失，B就会超时重传释放报文，A则返回确认，并重置计时状态
除此之外，还有一个保活计时，例如客户机卡住了，如果超过两小时，服务器就关闭这样。