负责hosts之间的逻辑通信

负责程序进程之间的逻辑通信(依赖,加强了网络层服务)

| 原理 | - 主机接收IP数据报 - 每个数据报有S_IP,D_IP - 每个数据报携带一个报文段 - 每个报文段有一个S_Port number,D_Port number- 主机使用IP&Port numbers就能直接找到对应的socket- 参考: 关于port | 数据报报文段 |

对于接收host来说:

| 特征 | - 创建指定端口的socket- 一个UDP** socket是由一个二元组全面标识的- 接收UDP数据报时: - 检查报文段中dest port number - 通过port number直接引导到对应socket- 当s IP不同时,只要d IP和port一样,报文段就会引导至一样的socket | | —- | —- | | SP的作用** | segment中的dest port可供引导segment;而SP是在当接收方需要回发报文时,会从中取值,加上发送方IP作为地址 |

对于接收host来说:

| 特征 | - CP socket由四元组标识**,接收方使用四个值直接引导报文段到指定socket- server host可支持同时多个TCP sockets,下图- 因为四元组的区分,web服务器对一个client可以有不同的socket(不同端口),见下图 | | —- | —- | | 个人理解 | | | 所谓多路复用就是一条路可以同时传输多个来自不同links的segs,要做到这点,就需要区分segs,因此UDP中使用二元组,TCP中使用四元组,解复用自然而然就是”各回各家,各找各妈”** | |

| 特征 | - 无连接 - 没有s/r之间的握手; - 每个UDP上的seg都独立于其他segs被处理- 尽力而为的传输 - 丢包,乱序- 简单- seg的header更小- 无拥塞控制

| UDP seg中length指明了seg**的字节长度(data+header) | | :—-: | —- | —- | | 用于 | 适合loss tolerant以及rate sensative的程序,如:流媒体,DNS | | | 改进** | 企业为了并取优点,大都自己设计应用层协议实现原有传输层TCP中的可靠性保证,在传输层采用UDP协议,保证速度 | |

**principles of reliale data transfer(不理解FSM简单浏览本节即可,从题中学习)

data transfer protocol.如TCP就是传输层上的可靠传输协议 | | | 问题 | 可靠协议的下层协议也许不可靠.如TCP在网络层上不可靠的IP协议上传输 | | | 讨论目标 | 开发一个协议,能够考虑到底层带来的bits损坏或丢失升至丢包,注意的是可靠数据传输原理不针对某一层,在各层中都有体现 | | | 约定 | - rdt/udt: 可靠/不可靠数据- rdt_send():上层调用(如app),传输可靠数据- udt_send():由rdt调用,通过不可靠信道传输数据给receiver- deliver_data():rdt调用,传递数据给上层- rdt_rcv():当packets抵达信道的rcv端时调用 目前只考虑单向(unidirectional)数据传输,以下过程设计到FSM,有限状态机 | |

rdt1.0假设了完全可靠信道的可靠数据传输

| | - sender 接收高层数据,打包后通过信道传输- receiver 从底层接收packet,从中取数数据后传给较高层 | | :—-: | —- | | | 这种理想情况下,receiver无需提供任何信息给sender,因为无需担心出错 |

rdt2.0针对有bit差错信道的可靠数据传输

接收上层调用后把数据和checksum打包通过信道发送—>进入wait state:如果收到NAK,则重发packet继续当前state;如果收到ACK—>进入等待命令的下一状态注意:当**sender等待ACK/NAK时,无法接收上层调用,这种机制叫做”停等”(stop-and-wait)- receiver 收到packet后,如果pkt中有bit错误,返回NAK;如果没有错误,提取数据,传递数据,返回ACK | | 理解 | 此时需要考虑到确认信息的需求—自动重传请求协议(Automatic Repeat reQuest, ARQ),协议中有三种应对bit差错的地方:- 差错检测- 接收方反馈: - ACK, acknowledge:肯定确认,理论上只要一个bit:1 - NAK, negative ~:否定确定,同样一个bit:0** |

FSM

receiver端的corrupt表示pkt有误 | | R | | 等待传入0状态:①如果发现传递出错(corrupt),则打包返回NAK,继续等待传入0状态;(错误分组)②如果接收到pkt1,传递无误,则返回ACK,继续等待传入0状态(失序分组)③如果发现pkt0,传递无误—>提取数据,传递数据,返回ACK(正常分组)—>进入等待传入1状态 |

优化rdt2.1得到2.2:NAK省略/冗余ACK

等待调用0状态—>打包发送pkt0—>停等0状态:①当收到ACK1或ACK/NAK混淆时,重发pkt0,继续停等0状态②当收到ACK0且反馈本身无误(notcorrupt)—>进入等待调用1状态- Receiver 等待传入0状态: ①收到pkt1或传递出错,发送ACK1②收到pkt0且传递无误—>提取数据,传递数据,返回ACK0—>进入等待传入1 | | 理解 | 冗余ACK体现在:进入①前,Sender必定收到了ACK1,再次进入①收到ACK1,说明Receiver没有正确接收pkt0 |

rdt3.0即比特交替协议(alternating-bit protocol)实现了有bit差错和丢包的可靠数据传输

FSM

基本类似rdt2.2版本,等待调用0状态->打包发送pkt0,开始计时—> 停等0状态:①收到ACK1或ACK/NAK混淆,触发计数器进入②(计时一直进行)②时间到,重发pkt0,重新计时③收到ACK0且反馈本身无误,停止计时—>进入等待调用1状态- Receiver 等待传入0状态: ①收到pkt1或传递出错,返回ACK1,保持等待0②收到pkt0且传递无误,返回ACK0—>进入等待传入1状态 |

总结rdt3.0的四种运行,分组号总在01间交替,因此叫比特交替协议

GBN即回退N步

| 模式 | | - base:标识已发送但还未ack的pkt- nextseq:标识待发送的pkt- N:窗口尺寸,即缓冲大小, seqbase=seq,无待发送pkt | | :—-: | :—-: | —- | | 可靠性 | | sender1. 初始base=(next)seq=1,此后只要seq1. 如果收到正确返回,base++.当base==seq说明buffer里没有pkt等待确认,停止计时,否则重启计时;1. 收到任何ACK重置timer1. 当时间到,重发当前窗口从[base]~[seq-1]的所有pkt | | | | receiver1. 初始化(expect)seq=1;1. 接收到正确且合序的pkt,提取数据,返回对应pkt,seq++;1. 其余默认情况下返回当前最大正确顺序seq的pkt; | | 特征 | 1. 顺序性:对于sender,必须收到base的ack才能窗口右移,否则do nothing;对于receiver,必须接收expectseq的pkt才能返回pkt并seq++1. 按窗口重发:当timeout时,无论处于sender的[base]~[seq-1]的pkt是否能正确到达,重发所有(回退)1. 积累确认,对序号为n的分组确认时,表明接收方对n和n之前所有的pkt都正确接收 | | | 示意 | | |+n即buffer未满,就可接收数据打包发送,然后seq++;+n,窗口未满,可继续打包

SR—Selective Repeat

只有收到窗口中最小pkt的ack后base++;当timeout后,重发当前最小未确认的pkt,重启计时器- receiver 对于在窗口中的pkt,正确接收后返回ack,不用考虑顺序;对于冗余/错误pkt,do nothing由sender的timer处理,时间到后对面自然会重发 | | 模式 | | |

| 组成 | - 一台host上的(发送)buffer,变量和进程socket- 另一台host上的(接收)buffer,变量,进程socket 注意:两台host之间的网络元素(routers,switchers)都没有为连接分配cache和变量 | | | :—-: | —- | —- | | 特点 | - 面向连接的:两个进程在数据传输之前,必须相互”握手”—相互发送预备报文段以确保数据传输的参数- 一一对应:一个sender,一个receiver- 可靠的有序字节流- send/receive buffer- full duplex data(全双工数据):在一条链接中的双向数据流; - MSS:maxmium segment size最大报文段长度,TCP可从buffer中提取放入segment中数据数量的最大限制- 流控 | | | 流程 | 三次握手 | | | | 连接建立 | | | | 数据封装传递 | | | 对比UDP | - TCP提供:可靠有序传输,流控,拥塞控制,- UDP仅提供:process2process投递, 数据校验(checking) | |

右图👉 A:发出C,C的第一个byte为42,A期待收到79B:发出C,C的第一个byte为79,B期待收到43 | | | —- | :—-: |

网络层的IP服务不可靠,TCP在不可靠之上建立可靠数据传输服务:确保一个进程从其接收缓存中读出的data flow是无损,无间隙,非冗余,按序的数据流**

TCP**重传:只能被timeout和duplicate acks触发 | ACK丢失 | 早熟(timeout过早) | 积累ACK** | | —- | —- | —- | | | | 只要sender收到的ACK正确无误,则说明receiver对之前的PKT都正确接收,则sender可以放心的一次性确认,不用在乎中间ACK丢失 |

快速重传**(Fast retransmit)** | | 如果完全依靠timeout触发重传,效率不够高,比如窗口第一个pkt丢失,可能发出多个pkt后才能timeout.GBN因此引入快速重传,当sender收到多个冗余ACK后,判断该pkt丢失,不管timeout,立即重传 | | :—-: | —- |

为了不溢出,必须保证(rwnd标识接收窗口)Last**ByteRcvd-LastByteRead≤RcvBufferrwnd = RcvBuffer-[LastByteRcvd**-LastByteRead |

三次握手 | | - 第一步: client发送一个特殊的TCP报文段,其中不含app层数据,但header中包含一个标志位SYN,被设为1 SYN=1,seq=client_isn- 第二步: server收到特殊seg,从中提取SYN,为TCP连接分配buffer和变量,向client发送允许连接报文段SYNACK,不含数据 SYN=1,seq=server_isn,ACK=client_isn+1- 第三步: client收到SYNACK,也为连接分配buffer和变量,同时发送另一个seg给server,对server的seg进行确认,此时连接已经建立,SYN置为0,可以携带数据 SYN=0,seq=client_isn+1,ACK=server_isn+1- 之后: 此后可以互相发送seg,在每个seg中SYN都被置为0 | | :—-: | —- | | | WireShark抓包:- 阶段一:Seq=0,ACK=0,SYN=1- 阶段二:Seq=0,ACK=1,SYN=1- 阶段三:Seq=1,ACK=1,SYN=0 | | | |

四次挥手 | | client应用进程关闭socket- 第一步 TCP向server端进程发送一个特殊seg,header中包含标志位FIN,设为1- 第二步 server收到FIN,回复ACK然后- 第三步 server发送自己的终止seg,FIN设为1- 第四步 client收到FIN,回复ACKserver收到ACK,连接关闭 | | :—-: | —- |

TCP状态序列 | client | server | | —- | —- | | | |

拥塞现象是指到达通信子网中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信死锁**拥塞控制是链路上的控制；流量控制是S/R端的控制

| 2发送方,1无限缓存路由 (路径带宽R,λ**in**单位byte/s) | | —- | | 实际拥塞情况:左—troughout与发送速率关系;右—delay与发送速率关系分析: a)两条路径同时发送,每条路径带宽最大R/2,因此左图在小于R/2时吞吐量与速率成线性关系,当到达R/2后,无法超出带宽,保持R/2b)当λin接近R/2时流量强度接近并超过,不可避免的开始排队并发展成无限期排队(参考:Ch1:流量强度) | | 2发送方,1有限缓存路由 | | 由于缓存有限,会发生丢包,该情况下引入”重传”机制:- λ**in表示sender应用层->传输层传递初始msg速率- λin‘表示sender传输层->网络层传输初始seg或重传seg速率,也叫网络的供给载荷(offered load)- λ**out表示receiver把报文段从传输层->应用层速率 分析a)假设hostA只在buffer空闲时发送分组,此时λ**in=λin‘b)假设hostA在确认一个packet丢失后才重发,当时(初始数据+重发数据)等价于网络中每发送0.5R数据,其中有0.333Rbyte/s是初始数据,0.166Rbytes/s是重发数据c)假设hostA的timer设置较短,会提前重传,此时效率更为低下 | | 4发送方,N有限缓存路由&多跳路径 | | 考虑A->C,经过R1,R2,此时R2被共享,区分:此时可以看到每个路径的带宽R可被一个host完全占有- 当λin‘较小时,对吞吐量的影响类似上一情况- 当λin‘较大时： - 理论通过R2的A-C流量最多为R(R1到R2) - 但此时如果B-D的供给载荷增大,二者会竞争,甚至死锁，A-C的吞吐量可能趋于**0，即如图所示情况 - 此外**,当分组仅丢失在第二跳时,第一条的传输也完全无意义** |

因为TCP连接每一端保存:接收buffer+发送buffer+变量(LastByteRead,rwnd)在sender端额外加入拥塞窗口**(congestion window,cwnd),**保证

主要有三个部分①慢启动②拥塞避免③快速恢复,①②是TCP强制部分,区别在于对收到ACK做出反应时增加cwnd长度的方式,③是推荐部分,非必需

| 慢启动 | - 初始:给cwnd起始设置为1MSS(最大报文段长度)的较小值,使得初始速率为MSS/RTT- 传输:之后每次sender确认一个seg后,把cwnd增加一个MSS （第二次,sender发出两个seg,因此会有两个ACK,sender对cwnd加两个MSS,下次同时发出四个seg…依次类推达到cwnd每次翻倍的效果）- 结束:发生拥塞后,有三种结束慢启动增长cwnd的方式 1. 当发生timeout标识的拥塞sender把cwnd重置为1—>重启慢启动过程;同时设置ssthresh为cwnd/2 1. 当cwnd==ssthresh(**慢启动阈值**)时结束慢启动且sstresh=cwnd/2—>拥塞避免 1. 如果发生快速重传(Fast retransmit)—>快速恢复 | | | :—-: | —- | :—-: | | 拥塞避免 | - 传输:如果进入拥塞避免,此时如果cwnd继续翻倍,很容易又进入拥塞,因此采用每次cwnd增长一个MSS,通用实现一般是接收到ACK后对cwnd增加MSS(MSS/cwnd) (当MSS=1000,cwnd=8000:假设一个RTT发送8个segs,当一个seg的ACK传达到sender,cwnd增加1000(1000/8000)=125,当RTT结束,cwnd共增加1000)- 结束:丢包事件发生 1. 当由超时引发(说明拥塞):同上cwnd**=1,sstresh=cwnd/2—>**慢启动 1. 当被3冗余ACK触发(说明只是出错,不一定拥塞),反应不应剧烈—>快速恢复**:cwnd减半,每个冗余ACK使cwnd++,最终产生的效果为cwnd=1/2cwnd+3,sstresh=1/2cwnd—>拥塞避免 | | | 快速恢复 | - 进入快速恢复后,立刻重传丢失的seg,重传完毕—>cwnd减半,每个冗余ACK使cwnd++,最终产生的效果为cwnd=1/2cwnd+3,sstresh=1/2cwnd—>拥塞避免- 如果重传未抵达就发生timeout,则cwnd=1,sstresh=cwnd/2—>慢启动 | | | 小结 | TCP拥塞控制称为”additive increase,multiplicative decrease”(加性增,乘性减,AIMD),因此期cwnd变化情况如右图所示* | |

设cwnd长度为w字节,AIMD机制使得连接传输速率在w/2RTT(减半)和W/RTT(起始)之间变化(递增),因此:

假设1500字节的seg和100ms的RTT,10Gbps发送速率.要求达到10Gbps的吞吐量,上述公式求得W应该达到83333个seg,此时关注seg的丢失,需要保证考虑丢失的情况下依然保证10Gbps的速率

因此TCP实现了公平性 | | 并行TCP | - 因为无法阻止TCP应用创建多个并行连接,公平性无法解决- 一个app可以创建多个TCP连接传输一个对象,从而抢占大部分带宽 | | | UDP | 实时多媒体(Internet电话,视频会议)不愿意在TCP运行,因为不想被传输速率遏制.使用UDP时:即便网络拥塞,数据也要以恒定速率发送,即便丢包,不愿意把速率降至”公平”,以保证不丢包 | |