charter3作业.doc

R3: UDP比TCP 应用层能更好地控制要发送的数据和发送的时间 无需连接建立 无连接状态 分组首部开销小 R5: 可以 只需根据RDT3.0的方式在应用层实现 R6: SP Y DP X R7:两个进程都进入主机C中的同一个socket 主机C通过两个进程的不同源端口号区分不同主机来的不同进程 R8：不；因为WEB SERVER运用的是TCP而非UDP，不同主机进入C的不同进程通过其不同的源IP和源端口号分配到不同的socket中。 所有socket都有端口号80，。。。 R14: a：20bytes b：ACK=90 R15：FFTFTFF R17：错，其阈值将被设置为拥塞窗口目前值的一半（乘性减）。 P1：a：A到S的源端口号X 目的端口号23 b：B到S的源端口号Y 目的端口号23 c：S到A的源端口号23 目的端口号X d：S到B的源端口号23 目的端口号Y e：YES f：NO P2：B到A（左）目的IP:A目的端口号7532 源IP：B源端口号80 B到A（右）目的IP：A 目的端口号26145 源IP:B源端口号80 B到C目的IP：C 目的端口号26145 源IP:B源端口号80 P5：a b c： P18：a：窗口长度N=3,当前期待得到的序号K的分组。1：当前期待得到K，可能的情况为K-1之前的分组已接收完成，所以窗口内的SEQ-NUM为[K,K+N-1]。2当前期待得到分组K，K为最后一个期待的分组，K-3之前的分组已接收完成，所以窗口内的SEQ-NUM为[K-N,K]。 b：如果接收方在等待分组K,那么它已经接收(并确认)了分组K-1以及在这之前的N-1个分组.如果所有这N的ACK都没有被发送方接收到,那么值为[K-N,K-1]的ACK信息可能仍在回传.因为发送方已经发送了分组[K-N,K-1],那么发送方肯定已经接收到了分组K-N-1的ACK.一旦接收方发送了分组K-N-1的ACK,它就不会在发送低于K-N-1的分组的ACK.因此发送方接收到的所有报文的ACK字段的可能值为从K-N-1到K-1. P19：a：T 超时重传。T1时刻发送分组1和2，T2时未收到ACK，超时重传。T3时收到第一次发送分组的返回ACK，窗口前移发送3和4，T4时收到重传的返回ACK在窗口外。 b：T 同a c：T d：T 当窗口尺寸为1时,SR,GBN,的比特交替协议在功能上相同.窗口尺寸1排除了失序分组的可能性.在这种情况下,一个累积的ACK就是一个普通的ACK.因为在窗口内它只能与一个分组有关. P21：窗口大小N≤K/2 P22: P23: a：有232 = 4,294,967,296个可能的序列号.所以L=232 ≈ 4.19 Gbytes. b：4294967296/(1460-66)=3081038…324 14600.000146 T=3081038*0.000146+(390= 449.831587s P24:a：SEQ-NUM 408 SP 1028 DP 80 b：SEQ-NUM 408 SP 80 DP 1028 c：SEQ-NUM 358 直到收到第一个数据前都等待358. d： P30: 23. SendBase:是最近未被确认的字节的序号.SendBase-1是接收方已正确按序接收到数据的最后一个字节的序号. LastByteRcvd:从网络中到达的并且已经放入主机B接收缓存中的数据流最后一个字节的编号. 在任一给定时刻t,SendBase-1是发送方知道的已经被接收方正确的按序接收的最后一个比特的序列号.在t时刻被接收方(正确的和按序的)接收到的真正的最后一个byte要比在链路上传输的ACK要大所以 SendBase–1 ≤ LastByteRcvd P31: 24. y:发送方接收到的最新ACK的值 在t时刻,发送方接收到的ACK的值为y,据此发送方可以确认接收方已经接收了序号到y-1的数据.如果y ≤SendBase或在线路上有其他的ACK,在t时刻接收方(正确的和按序的)接收到的真正的最后一个byte要比y-1大.所以y-1 ≤ LastByteRvcd P35 :如果TCP是停等协议，那么将超时间隔加倍作为拥塞控制机制已经足够。然而，TCP使用流水线（因此不是停等协议），这允许发送方有数倍的未被确认的报文段。当端到端路径高度拥塞时，将超时间隔加倍不会阻止TCP发送方在第一次发送时发送大量报文段。因此就需要一种拥塞控制机制，当出现网络拥塞的迹象时，阻止“接收来自上层应用的数据” P