很多东西读的时候不理解，只能等lab，
纸上得来终觉浅，绝知此事要躬行
1.运输层介于网络层和应用层之间，考虑两个问题，一是怎么为应用层提供可靠的传输，二是怎么控制拥塞
从应用层的角度看，运输层提供了逻辑通信，相当于屏蔽了底层实现，
运输层是在端系统中实现的，
做个不恰当的类比，运输层相当于“网线”，所有进程想要传输的东西都会包装成一个运输层报文传给那个网线的口子那里
网络层相当于路由器。
书上的类比是兄弟姐妹寄信
为此就有了多路复用和多路分解，因为包装就是合成，到达就是要分解成不同的给不同的进程，为此报文段要有源端口号和目的端口号
2.rdt(reliable data transfer):
推导过程
1.假设底层可靠，那么直接传输就行
2.假设底层可能出现bit损坏，那么就要检验，检验失败就要往回发nak，来重传，在等待ack过程中，发送方摸了，但是因为这个nak或者ack可能损坏，所以发送方收到不清楚的ack或nak时直接重传，因为有着重传，所以要有编号来告诉接收方这个包是新的还是重传的，这个标记只要是01就行了，至此功能已经全部正确。但是效率太差，因为会停下来等待
解决方法是流水线，一次传多个分组，为此要增加序号范围，双方都要缓存分组，要有差错恢复，差错回复有GBN(go back n)和SR(selective repeat),GBN又称滑动窗口协议：以最早发送但没有确认的分组为窗口左端，窗口大小不变，最左边确认了，就向右移
序号必须在[0,2的k次方-1]间
GBN中确认是按序的，当一个流水线中的分组没有确认时，会重传这分组及之后的分组
选择重传协议
当接收方基确认时，接受方窗口前进至连续的确认的位置，发送方类似接收方；
要注意一种特殊情况：当接受方发送的ack丢失时候，发送方会超时，并重传，因此接收方要对收到在窗口之前的分组做出发送ack的回应，来使得发送方的窗口向后移动，避免一直等待不动，而发送方与接受方的当前看到的窗口最大可能相差到刚好错开，此时必须要使序号空间大于等于2倍的窗口长度
tcp协议
1.3次握手，前两次理解为hi和hello，客户发送的第三个报文可承载有效报文段
2.mss（max segment size）最大报文段长度+tcp/ip的首部行（通常40字节）=最大链路层帧（max tamsform unit）
3.tcp结构：
首部一般20字节，可以通过首部长度和选项改变，但首部长度一般空白，所以默认20字节，
序号和确认号是两个重要的部分
tcp以字节编号，序号就是字节号，不是数据报号，比如，有5000个字节，mss为1000字节，那么第一个报文段有1000字节，第二个报文段起始为1000
确认号比较难：a向b传数据，b得到了一段数据流，假设断在了200，那么b就会在他向a发送的报文段中的确认号填上200，也就是期望得到的字节，也就是ack就是想要得到的下一个字节，服务器和客户的首字节随机选择
tcp超时时间设置：涉及统计学，记住两个公式，跳过
快速重传：如果连续发送报文段的一个报文段丢失了，但之后的还在送到，那么接受方只能发送ack：当前最大已确认的序号，这是根据tcp协议所理解的，{其实就是一段代码，当ack大于当前的sendbase时候；sendbase=ack；因为tcp是累计确认的，如果直接ack后面的，那么丢失的就永远丢失了}，当发送了三个冗余ack时候，就执行快速重传
这儿的sendbasa=ack和选择重传协议的有着本质区别:这儿对应的情况是前一个ack没了，而选择重传是按序号确认，可以确认后面的，但是base到未确认间不能超过窗口长度，base确认了向后到没有确认的那个位置
总结一下，tcp接受方只维护最小的有序的已确认的字节流的最大序号。这样就是滑动窗口协议，但是很多tcp的实现中有缓存，并且用了选择确认，所以最好理解为滑动窗口协议和选择重传的结合
上面是tcp的正确性，接下来是tcp的拥塞控制
慢启动，加快速度，直到超时或3个冗余ack收到事件发生，然后调节拥塞窗口为拥塞时候大小的一半，然后在加速，一开始以指数上，到达一半使开始缓慢的加，（增加一个），
每个rtt内拥塞窗口长度加性增，乘性减
对于一个有瓶颈链路的tcp来说，短的rtt的更能抢占带宽