TCP和UDP 对比

• TCP(Transmission Control Protocol)，传输控制协议
• UDP(User Datagram Protocol)，用户数据报协议

UDP协议

• UDP是无连接的，减少了建立和释放连接的开销
• UDP尽最大能力交付，不保证可靠交付
• 不需要维护一些复杂的参数，首部只有8个字节(TCP的首部至少20个字节)
• UDP长度(Length) ，占16位，首部的长度 + 数据的长度

• 检验和：计算内容:伪首部 + 首部 + 数据
• 伪首部:仅在计算检验和时起作用，并不会传递给网络层

端口补充

• UDP首部中端口是占用2字节，可以推测出端口号的取值范围是:0~65535
• 客户端的源端口是临时开启的随机端口
• 防火墙可以设置开启\关闭某些端口来提高安全性
• 常用命令行
  netstat –an:查看被占用的端口
  netstat –anb:查看被占用的端口、占用端口的应用程序
  telnet 主机 端口:查看是否可以访问主机的某个端口

TCP协议

数据格式

数据格式

• 数据偏移 ，占4位，取值范围是0x0101-0x1111，乘以4得首部长度（20~60字节）(Header Length)。
• 保留，占6位，目前全为0。
• TCP的数据长度 = 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度
• 检验和跟UDP一样，TCP检验和的计算内容:伪首部 + 首部 + 数据
• 伪首部:占用12字节，仅在计算检验和时起作用，并不会传递给网络层
• 标识位
  URG(Urgent) ，当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
  ACK(Acknowledgment)，当ACK=1时，确认号字段才有效
   PSH(Push)
   RST(Reset) ，当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
   SYN(Synchronization) ，当SYN=1、ACK=0时，表明这是一个建立连接的请求 ，若对方同意建立连接，则回复SYN=1、ACK=1
   FIN(Finish) ，当FIN=1时，表明数据已经发送完毕，要求释放连接
• 序号(Sequence Number)，占4字节
  首先，在传输过程的每一个字节都会有一个编号
  在建立连接后，序号代表:这一次传给对方的TCP数据部分的第一个字节的编号
• 确认号(Acknowledgment Number)占4字节
  在建立连接后，确认号代表:期望对方下一次传过来的TCP数据部分的第一个字节的编号
• 窗口(Window)占2字节
  这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小(字节为单位)

TCP可靠传输

• 如果接收窗口最多能接收4个包 ，但发送方只发了2个包
• 接收方如何确定后面还有没有2个包? ，等待一定时间后没有第3个

SACK协议（选择性确认）

• 在TCP通信过程中，如果发送序列中间某个数据包丢失(比如1、2、3、4、5中的3丢失了)
• TCP会通过重传最后确认的分组后续的分组(最后确认的是2，会重传3、4、5)
• 这样原先已经正确传输的分组也可能重复发送(比如4、5)，降低了TCP性能
• 为改善上述情况，发展出了SACK(Selective acknowledgment，选择性确认)技术
  告诉发送方哪些数据丢失，哪些数据已经提前收到
  使TCP只重新发送丢失的包(比如3)，不用发送后续所有的分组(比如4、5)

问题

为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层?
因为可以提高重传的性能
需要明确的是:可靠传输是在传输层进行控制的
如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

TCP流量控制

接收方缓存区满了，发送方还在疯狂着发送数据 ，只能把数据包丢掉，大量的丢包会极大着浪费网络资源 ，所以要进行流量控制

• 什么是流量控制?
  让发送方的发送速率不要太快，让接收方来得及接收处理
• 原理
  通过窗口字段控制发送速率
  发送方窗口大小不能超过接收方给出窗口大小
  收到窗口的大小为0时停止发送数据

TCP拥塞控制

• 拥塞控制 ，防止过多的数据注入到网络中 ，避免网络中的路由器或链路过载
• 拥塞控制是一个全局性的过程 ，涉及到所有的主机、路由器 ，以及与降低网络传输性能有关的所有因素 ，是大家共同努力的结果
• 相比而言，流量控制是点对点通信的控制

拥塞控制方法

• 慢开始(slow start，慢启动)
   cwnd的初始值比较小，然后随着数据包被接收方确认(收到一个ACK)
  cwnd就成倍增长(指数级)

• 拥塞避免(congestion avoidance)
  ssthresh(slow start threshold):慢开始阈值，cwnd达到阈值后，以线性方式增加
   拥塞避免(加法增大):拥塞窗口缓慢增大，以防止网络过早出现拥塞
   乘法减小:只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法(cwnd又恢复到初始值) 当网络出现频繁拥塞时，ssthresh值就下降的很快

• 快速重传(fast retransmit)
   接收方
  1.每收到一个失序的分组后就立即发出重复确认
  2.使发送方及时知道有分组没有到达
  3.而不要等待自己发送数据时才进行确认
   发送方
  1.只要连续收到三个重复确认(总共4个相同的确认)，就应当立即重传对方尚未收到的报文段
  2.而不必继续等待重传计时器到期后再重传

• 快速恢复(fast recovery)
  当发送方连续收到三个重复确认，说明网络出现拥塞 ，就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半
   与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值 ，而是把cwnd值设置为新的ssthresh值(减小后的值) ，然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大

名词解析

• MSS(Maximum Segment Size):每个段最大的数据部分大小 ✓在建立连接时确定
• cwnd(congestion window):拥塞窗口 rwnd(receive window):接收窗
• swnd(send window):发送窗口 ✓swnd = min(cwnd, rwnd)

拥塞控制方法 —— 快重传+快恢复

TCP三次握手

• CLOSED:client处于关闭状态
• LISTEN:server处于监听状态，等待client连接
• SYN-RCVD:表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
• SYN-SENT:表示client已发送SYN报文，等待server的第2次握手
• ESTABLISHED:表示连接已经建立

三次握手的主要目的是为了服务端和客户端双方交换信息。三次握手过程中并不会发送数据部分，只是头部信息交换。

问题

为什么建立连接的时候，要进行3次握手?2次不行么?
主要目的:防止server端一直等待，浪费资源

• 如果建立连接只需要2次握手，可能会出现的情况
  假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server
  本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
  于是server就向client发出确认报文段，同意建立连接
  如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了
  由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
  但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了
• 采用“三次握手”的办法可以防止上述现象发生
  例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接

第3次握手失败了，会怎么处理?
此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包
如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接

TCP四次挥手

• FIN-WAIT-1:表示想主动关闭连接 ，向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
• CLOSE-WAIT:表示在等待关闭
  当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
  在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
• FIN-WAIT-2:只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
• CLOSING:一种比较罕见的例外状态
  表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
  如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
  表示双方都正在关闭连接
• LAST-ACK:被动关闭一方在发送FIN报文后，最后等待对方的ACK报文 ，当收到ACK报文后，即可进入CLOSED状态了
• TIME-WAIT:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可进入CLOSED状态了 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
  ✓ 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
• CLOSED:关闭状态
• 由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等

TCP释放链接细节

• TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
• client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
  一般是等待2倍的MSL(Maximum Segment Lifetime，最大分段生存期)
  ✓ MSL是TCP报文在Internet上的最长生存时间 ✓每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟
  ✓ 可以防止本次连接中产生的数据包误传到下一次连接中(因为本次连接中的数据包都会在2MSL时间内消失了)
• 如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN
这时可能出现的情况是
  1 client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
  2 client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来 它可能是想跟server建立连接的

问题

为什么释放连接的时候，要进行4次挥手?
TCP是全双工模式
第1次挥手:当主机1发出FIN报文段时
✓ 表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
第2次挥手:当主机2返回ACK报文段时
✓ 表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
第3次挥手:当主机2也发送了FIN报文段时
✓ 表示主机2告诉主机1，主机2已经没有数据要发送了
第4次挥手:当主机1返回ACK报文段时
✓ 表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接