计算机网络知识点——12.传输层
概述：
传输层协议称为端到端或进程到进程的协议。因特网的传输层可以为两个进程在不可靠的网络层上建立一条可靠的逻辑链路，为它们提供字节流传输服务，并且还具有流控制功能和拥塞控制功能。
TCP/UDP报文：
因特网的传输层有两个协议：UDP和TCP。UDP协议提供不可靠的尽力服务，TCP协议提供可靠的字节流服务。
我们把传输层的数据单元（报文）称为数据段（segment）。
问：因特网传输层的主要协议为（）和（）。
答：UDP和TCP。
问：如果有效载荷为TCP，IP数据报的协议字段的值是什么?
答：6
传输层的多路复用和解多路复用：
端口号：
UDP协议和TCP协议如何知道把收到的数据段交给哪个上层进程呢？
利用数据段（segment）中的目的端口号（2个字节）
- 知名端口：0~1023。为提供知名网络服务的系统进程所用。例如: 80-HTTP， 21-ftp Control， 20-ftp Data， 23-telnet，25-SMTP， 110-POP3， 53-DNS
- 注册端口：1024~49151。在IANA注册的专用端口号，为企业软件所用。
- 动态端口：49152~65535。没有规定用途的端口号，一般用户可以随意使用。也称为私用或暂用端口号。
端口号1000是哪种类型的端口？
A.well-known ports
B.registered ports
C.private ports
答案：A
UDP协议：
用户数据报协议（User Datagram Protocol）只提供无连接的不可靠的尽力服务。发送给接收进程的数据有可能丢失，也有可能错序。
接收进程每次收到一个数据报，如果进程设置的接受缓冲区不够大，收到的数据报将被截断。
- 总长度： 整个UDP报文的长度。
- 源端口号和目的端口号：用于关联发送进程和接收进程。
- 校验和： 由伪IP头、 UDP头(校验和为0)和UDP数据形成。其中，伪IP头的协议号为17。如果发送方把校验和设置为0，接收方会忽略校验和 。 UDP长度就是UDP头部的总长度。
A.它提供了面向连接(connect-oriented)的服务.
B.传送的数据段会丢失.
C.具有保序性.
D.负责在进程之间传送数据.
E.接收进程收到的数据段数与接收缓冲区大小有关.
答案：BD。如果接收缓冲区不够大，收到的数据报将被截断。
问：下面哪个部分被加入到UDP数据段的校验和中?
A.UDP header(checksum filled with 0)
B.UDP data
C.Source IP address
D.Dest IP address
E.TTL(1B)and protocol(1B)
F.Header CheckSum(2B)in IP Header
G.0(1B)and protocol(1B) in IP Header
H.Length(2B)in IP datatgram
I.UDP Length(2B)
J.Iden in IP datatgram(2B)
K.flags(3b) and offset(13b) in IP datatgram
答：ABCDGI。包含UDP头，UDP数据，伪IP头中的源IP地址，目的IP地址，o和协议号，UDP的长度
传输控制协议（TCP）：
TCP（Transmission Control Protocol）为进程之间提供面向连接的可靠的数据传送服务。
TCP为全双工协议。TCP提供流控制机制，即控制发送方得发送速度，使发送的数据不会淹没接收方。作为因特网的主要数据发源地，TCP还提供拥塞控制机制。
TCP连接只能在两个进程之间建立连接，经过互联网可能会丢失和错序。
TCP协议的数据传送服务采用哪种工作方式?
A.simplex
B.half duplex
C.full duplex
答案：C
一个TCP连接提供可靠的字节流服务。字节流服务表示没有消息边界。例如：多次发送的数据可以放在一个数据段中传送但是不标识边界。
每个数据段的数据部分的最大长度（字节）不能超过MSS（Maximum Segment Size）。
每个TCP连接可以由四元组唯一标识：源IP地址，源端口号，目的IP地址，目的端口号。
TCP报文格式：
- 字节流中的每个字节均被编号。初始序号采用基于时间的方案，一般采用随机数，数据部分的每一个字节的编号为初始序号加1.
- 每个数据段的序号采用其数据部分第一个字节的编号。确认号为期待接收的下一个数据段的序号。只有设置了确认标识，确认号才有效。
- 头部长度以四个字节为单位。
- 校验和由伪IP头、TCP头和TCP数据部分形成。其形成方法和UDP协议类似。
- 紧急指针用于指出带外数据（out-of-band）的边界。标志URG为1时有效。
例：下图为一个普通TCP连接的数据传送图（不使用Nagle Algorithm,Delayed ACK,Fast Retransmission,Slow start等）, 请填空.
分析：datasize为最大可传数据段大小，win为接收窗口可接收大小。
| a | 9000 | 700 |
| b | 9700 | 300 |
| c | 9700 | 300 |
| d | 10000 | 0 |
| e | 10000 | 1000 |
| f | 10000 | 700 |
| g | 10700 | 300 |
| h | 10700 | 300 |
| i | 11000 | 0 |
问：长度分别为360字节、600字节、600字节和512字节的四个数据段通过一个TCP连接连续传送. 如果第一个数据段的序号为8000,其它数据段的序号是多少？
答：每个数据段的序号采用其数据部分第一个字节的编号。为8360、8960、9560.
问：TCP的紧急数据(urgent data)是带外数据，不属于字节流，true or false?
A.true
B.false
答案：A
- 发送窗口为确认号之后发送方还可以发送的字节的序号范围。接收方用通知窗口大小（advertised window）告知发送方修改发送窗口大小。
- 建立连接时的选项：MSS（Maximum Segment Size）、窗口比例（Scale）；是否使用选择性确认（SACK-Permitted）。Unix系统的默认值：MSS为536，SACKPermitted为False。 Windows 的默认值MSS为1460， SACK-Permitted为True 。
- 数据传送时的选项：选择性确认的序号范围(Seletive ACK,SACK)；时间戳等。
- URG: 包含紧急数据。
- ACK: 确认号有效。
- PSH: 告知接收方发送方执行了推送(Push)操作，接收方需要尽快将所有缓存的数据交给接收进程。
- RST: 重置(Reset)连接。因为连接出现了错误，通知对方立即中止连接并释放相关资源。
- SYN: 同步(Synchronous)序号标志，用来发起一个TCP连接。
- FIN: 结束(Finish)标志，表示不在发送数据。
*所有标志为1有效。
例：数据段中哪个标志可以令TCP协议把缓存数据立即发给接收进程?
A.ack
B.rst
C.psh
D.fin
答案：C。
问：如果TCP连接出现错误，TCP协议将发送标志 （） 为1的数据段，并立即结束连接.
答案：rst
TCP协议的工作过程：
问：以下哪个TCP会话是非对称的(asymmetric)?
A.Establish connection
B.Transfer Data
C.Close Connection
答案：A。只有建立连接过程是非对称的，为客户向服务器呼叫。
三次握手建立连接：
- 客户端需要知道副武器的IP地址和端口号。服务器收到客户端发来的连接请求（SYN报文）后查看是否有进程监听该端口：如有，则将此连接请求传给该进程，在该进程接受后，发回SYN+ACK报文；否则，服务器发RST拒绝它。
- 每一步均采用超时重传，多次重传后将放弃。重发次数和间隔时间依系统而不同。
- x和y为初始序号，分别用于两个方向的数据传送，它们一般采用基于事件的方案，如：随机数。两个方向的下一个数据段的序号分别为x+1和y+1。
- 头两个数据段确定选项：Scale，MSS，SACK-Permited
问：建立TCP连接的三次握手使用的标志分别是什么?
答：SYN,SYN+ACK,ACK
四次握手关闭连接：
- FIN报文采用超时自动重发方式。在若干次重发后依然没有收到确认，则发送RST报文给对方后强行关闭连接。不同的系统重发方法不同。x和y都是上一个收到的数据段的确认号。
- 先发送FIN报文的一方在ACK发送完毕后需要等待2MSL(Maximum Segment Lifetime）的时间才完全关闭连接。TCP标准中MSL采用60s，Unix采用30s。
例：请说明使用一次握手建立TCP连接会出现什么问题.
答：如果一次握手的话，也就是说客户端只要发送了连接请求就认为TCP连接。也许服务器根本就不存在或者没打开。如果继续发送数据的话，浪费带宽，再说客户端也需要服务器传来的初始序号和很多选项，这个都做不到。
例：请说明使用二次握手建立TCP连接会出现什么问题？（考虑恶意攻击的情况）
答：只有两次握手的话，服务器可能会因为遭遇恶意攻击而瘫痪，客户端可以发送大量伪造源地址的连接请求，服务器确认后以为连接已经建立，最后会耗尽资源，进而拒绝所有合法的连接请求，无法提供正常服务。（Dos攻击）
例：请说明使用三次握手建立TCP连接不能避免恶意攻击的情况。
答：即使使用三次握手，服务器也可能会因为遭遇恶意攻击而瘫痪，不过难度增加了很多。可能遭遇分布式的泛洪恶意攻击，黑客可以控制许多主机对一台服务器进行泛洪攻击，发送大量连接请求去请求服务器服务，耗尽服务器资源，使其无法为合法用户提供服务，从而使服务器瘫痪。（DDoS攻击）
问：发送FIN数据段的一方说明它不再发送任何数据了，true or false？
A.true
B.false
答：A。
例：主动发起关闭TCP连接的一方在关闭连接之前等待2MSL的原因是什么?
A.恢复连接.B.防止两个连接发生冲突.
C.等待接收TCP管道中的数据.
D.等待该连接的数据在因特网中消失.
答案：D
TCP滑动窗口：
- TCP协议使用选择性确认，不使用NAK
- 只有一个超时定时器。重传数据段时会重启该定时器
- 采用字节流方式，每个数据段使用其第一个字节的编号作为序号。确认号为期待接收的下一个字节的序号。
- TCP协议没有说明如何处理错序到达的数据段，要取决于具体实现。
快速重传：
如果发送方收到一个数据段的3次重复的ACK，它就认为其后的数据段（由确认号指出）已经丢失。
快速重传（fast retransmit）：在超时定时到期之前重传该数据段。
例：对于快速重传(fast retransmission), 收到多少个对某个数据段序号的确认(表示期待接收该数据段)将触发数据的重传?
答：4个。重复收到3个，总共收到4个
延迟确认：
采用延迟确认（delayed ACK）时，接收方并不在收到数据段立即进行确认，而是延迟一段时间再确认。如果这个期间收到多个数据段，则只需要发送一个确认。如果在这个期间接收方有数据帧要发往发送方，还可以使用捎带确认（piggybacking）。
大部分的系统的(Windows，Unix）的延迟确认时间为200ms。
选择性确认：
选择性确认允许接收方把收到的数据块通过数据段的选项告知发送方，使发送方不会重传这些数据块。
TCP超时计算：
初始公式：
Jacobson算法：
例：采用Jacobson算法计算TCP会话的超时时间,如果EstimatedRTT=10ms, DevRTT=1ms,SampledRTT=20ms, 问：新的DevRTT、EstimatedRTT和TimeoutInteval分别为多少毫秒?
解：利用公式，DevRTT:3.25，EstimatedRTT：10+1/8*10=11.25，Timeoutinterval：11.25+4*13/4=24.25.
Karn算法：
例：如果一个TCP数据段的传送在超时时间(30ms)内未收到确认, 重传数据段的超时时间应该设为多少毫秒?
解析：60
拥塞的表现：
简单来说：“太多的主机发送太快太多的数据给网络处理”。这不同于流控制。
表现：
- 丢包（路由器上缓冲区溢出）
- 长延迟（在路由器缓冲区中排队）
拥塞控制方法：
拥塞控制（Congestion Control）的两大类方法：
端到端的拥塞控制：
- 没有来自网络的明确的反馈
- 终端系统通过丢包和延迟推导的拥塞
- TCP协议的方法
网络辅助的拥塞控制：
- 路由器反馈给终端系统：1.用一个比特指出拥塞发生（SNA,DECbit，TCP/IP ECN,ATM）2.向发送方给一个明确的发送速率。
TCP拥塞控制：
- 超时或收到3个重复ack就认为丢包了，看作拥塞发生了。
- TCP通过减少发送速率来控制拥塞。发送速率与发送窗口大小有关：
发送速率 rate=SWS（Sending Window Size）/RTT
- 引入拥塞窗口变量CongWin来限制SWS
SWS = Min(CongWin,AdvWin) （AdvWin为接收窗口大小）
- TCP协议改变CongWin的三种机制：
- 加性增乘性减（AIMD）
- 慢启动（slow start）
- 在超时时间之后的保守方法
答：1000， SWS = Min(CongWin,AdvWin) （AdvWin为接收窗口大小）
加性增乘性减：
加性增（additive increase）：每个RTTCongWin增加1MSS，直到丢包
乘性减（multiplicative decrease）：在丢包后CongWin减半
问：如果AIMD(Additive Increase Multiplicative Decrease)用于TCP连接的拥塞控制,当发生拥塞时, CongWin=10MSS, 它的新的CongWin是多少? 在4个RTT之后, 它的CongWin又是多少?
答：5MSS,9MSS。
慢启动（slow start）：
- 初始时，CongWin设为1MSS，阈值（threshold）设为65535，发送一个数据段。
- 在当前窗口所有数据段的确认都收到之后，CongWin加倍。（实际上，每收到一个确认CongWin增加一个MSS。）把它称为慢启动（slow start）是因为这个方法比立即采用通知窗口更慢。
- 当拥塞发生时，把当前CongWin（或SWS）的一半保存为为阈值（threshold），然后CongWin又从1MSS开始慢启动。
- 当CongWin增长到等于或大于阈值（threshold）时，在当前窗口所有数据段的确认都收到之后，CongWin增加一个MSS。（Congestion Avoidance）实际上，此时每收到一个ACK，CongWin增加SegSize*SegSize/CongWin。如果发生拥塞，转3。
- 用系统参数TCP_MaxWin（一般为65535）限制CongWin的大小。
*SegSize为被确认的数据段的大小
*假设算法开始通知窗口大小AdvWin=65535
慢启动和快速恢复（Fast Recovery）：
具体来说快速恢复的主要步骤是：
Tahoe算法：
在慢启动阶段，以指数式递增，当达到阈值时，以线性方式递增，每次增加1，如果连续收到3个重复确认，快速重传，之后TCP返回慢启动状态。
Tahoe不存在快速恢复算法。这也是它的不足之处。在收到3个重复ACK或者在超时的情况下，Tahoe置cwnd为1，然后进入慢启动阶段。这一方面会引起网络的激烈震荡，另一方面大大降低了网络的利用率。
也就是说，一旦发现掉包，那么cwnd就被打回原形。
没有快速恢复算法，在恢复丢失数据包期间，不能发送新的数据包，这段时间的吞吐量为0。而实际上如果利用这段时间来发送适量的新数据包，可以大大的提高丢包时的传输效率。这就是快速恢复名称的由来。
例：假设Tahoe算法被用于TCP连接的拥塞控制, 当超时发生时, CongWin等于16MSS, 如果期间没有发生超时，在5个RTT之后CongWin是多少?
答：拥塞发生时，阈值变为8MSS，所以为：2mss,4mss,8mss,9mss,10mss.结果为10mss。
Reno算法：
Reno与Tahoe相比，增加了快速恢复阶段，也就是说，完成快速重传后，进入了拥塞避免阶段而不是慢启动阶段。
在快速恢复阶段，每收到重复的ACK，则cwnd加1；收到非重复ACK时，置cwnd = ssthresh，转入拥塞避免阶段；如果发生超时重传，则置ssthresh为当前cwnd的一半，cwnd = 1，重新进入慢启动阶段。
Reno快速恢复阶段退出条件：收到非重复ACK。
例：假设Reno算法(快速恢复算法)被用于TCP连接的拥塞控制, 当收到三个重复的ACK时,CongWin等于16MSS, 如果期间没有发生超时，在5个RTT之后CongWin是多少?
答：13MSS，收到非重复ACK，置cwnd=ssthresh，转入拥塞避免阶段，9mss,10mss,11mss,12mss,13mss。
问题1：长肥管道：
如果一个连接被看成是两个端点之间的管道 ， 它的容量（可以容纳的未确认比特数）是多少呢？如果容量很大 (long fat pipe), 会出现什么情况？一个连接的时延带宽积可表示为：capacity(b)=bandwidth(b/s)×round-triptime(s)，用于表示通道的容量，也可称它为两端的管道大小。
具有大的带宽时延乘积的网络被称为长肥网络（Long Fat Network，即LFN），而一个运行在LFN上的TCP连接被称为长肥管道。
在一个窗口内发生如果只有一个报文丢失，丢包发生时，由于SWS的限制，管道将会被清空。 使用快速重传和快速恢复算法可以使管道避免耗尽。
- LFN需要更大的窗口来提供最大的吞吐量：TCP首部中窗口大小为16bit，因此窗口大小最大为65535字节，这就将发送方发送但未被确认的数据的总长度限制到了65536字节。对于LFN管道，这可能会出现所有的数据都还未到达接收方，但是发送方已受限于窗口大小而不能继续发送的情形，这就极大的降低了网络的吞吐量。使用窗口扩大选项（Windows Scale Option）来解决这个问题。
- LFN存在序号回绕问题：TCP对每个字节数据使用一个32bit无符号的序号来进行标识。TCP定义了最大的报文段生存时间（MSL）来限制报文段在网络中的生存时间。但是在LFN网络上，由于序号空间是有限的，在已经传输了4294967296个字节以后序号会被重用。如果网络快到在不到一个MSL的时候序号就发生了回绕，网络中就会有两个具有相同序号的不同的报文段，接收方将无法区分它们的顺序。在一个千兆比特网络（1000Mb/s）中只需要34秒就可以完成4294967296个字节的发送。使用TCP的时间戳选项的PAWS(ProtectionAgainstWrappedSequencenumbers)算法（保护回绕的序号）可以解决该问题。
- LFN内的分组丢失会使吞吐量急剧减少：根据TCP的拥塞控制，丢失分组会导致连接进行拥塞控制，即便是由于冗余ACK而进入了快速恢复，也会使得拥塞窗口降低一半，而如果是由于超时进入了慢启动，则拥塞窗口会变为1，无论是哪一种情形，发送方允许被发送的数据量都大量减小了，这会导致网络吞吐量降低。选择确认（SACK）可以用来部分避免该问题，采用该技术使得接收方可以有选择的对无序到达的报文段进行确认而不是采用累积确认，这样被确认的报文段就不会超时，也不会有冗余的ACK。
- LFN上需要更好的RTT测量机制：引入时间戳选项。（timestamp，TS）
A.WinScale
B.Selective Acknowledgement
C.MSS
D.timestamp
答：D，时间戳。
问题2：死锁现象：
当发送窗口为0时，如果取空接收缓冲区之后发送的确认丢失，就会发生死锁。因为发送窗口未收到确认，所以继续为0，无法发送，但是接收方已经无法发回确认了，所以就产生了死锁。
解决方法：
在发送窗口为0之后, 发送方如果有数据要发送，则启动坚持定时器(Persist Timer)，定期从要发送的数据中取一个字节发送出去(Window Probe)，直到收到不为0的通知窗口为止。
例：假设一个TCP连接的接收缓冲区大小为4600字节，如果该连接的一个AdvWin为（ ） 的确认到达后，紧接着AdvWin为 （ ） 的另一个确认丢失了，该连接会发生死锁现象。
答：0,4600.
如何解决本题的死锁问题：
答：当发送方有数据要发送时定期发送一个字节给接收方。
问题3：傻瓜窗口症候（Silly Window Syndrome）：
情形1：发送进程有很多小批量数据要发送，例如：用telnet作为远程终端。
Nagle算法——启发式算法：
(1) 立即发送一个数据段，即使发送缓冲区只有一个字节。
(2) 只有收到上一个数据段的确认或者发送缓冲区中数据超过MSS，才可以发送下一个数据段。
(3) 对于即时性要求高的地方，如， Window方式的鼠标操作，要关闭Nagle算法。
例：在建立TCP连接, 发送方收到接收方的参数“MSS=500, Sequ#=10000, Win=1000”之后, 发送方每10毫秒发送两个字节. 如果使用Nagle算法并且RTT等于 42ms, 问该发送方发送前三个数据段的有效载荷分别有多少字节?
解析：主要两个原则：1.立即发送一个数据段2.收到上一个数据段的确认才发送下一个数据段
第一个数据段立即发送前两个字节，然后到42ms之间累计了8个字节，在42ms收到确认时一并发送，在42ms到84ms之间累计8个字节，并在84ms确认到达时一并发送。所以为：2 8 8.
情形2：接收进程频繁取走小批量数据：
Clark算法：当接收缓冲区的空闲块大小变得很小时，要等到空闲块大小为缓冲区大小的一半或达到MSS时才发送确认。
例：一个TCP连接的接收缓冲区大小为2000, 接收方提出的MSS为500。如果使用了Clark算法，在发送了AdvWin=0的确认之后，接收方空闲块的大小为多少字节时才发送下一个确认?
解析：空闲块达到缓冲区一半或MSS时才发送确认，所以至少达到500。
TCP定时器：
每个连接只针对第一个未确认数据段启动重传定时器（retransmission timer）。所有数据段都已确认，则关闭它。超时重传或发送窗口移动时要重启该定时器。
持续定时器（persist timer）用于保持窗口大小信息流动即使连接的另一端关闭了接收窗口。
保活定时器（keepalive timer）在长时间没有交换数据段之后，用于检测连接的另一端是否出了问题。
处于TIME_WAIT 状态的连接一方需要等待2MSL秒，时间到才能关闭连接。
启动阶段。