TCP

• 传输控制协议。
• 面向连接的，提供可靠交付
• 有流量控制、拥塞控制
• 提供全双工通信
• 面向字节流
• TCP连接是一对一的
• 首部20个字节

TCP首部格式

序号：对字节流编号，序号是301说明字节流第一个编号为301，如果此段长度为100，下一个报文段的序号应该为401

确认号：期望收到的下一个报文段的序号。

数据偏移：首部的长度

确认ACK：ACK=1时确认号有效，连接建立后ACK=1

同步SYN：连接建立时用来同步序号：SYN=1，ACK=0是连接请求。SYN=1，ACK=1连接建立

终止FIN：释放连接

窗口：作为接收方让发送方设置其发送窗口的依据。

UDP

• 用户数据报协议
• 无连接，尽最大可能交付
• 没有拥塞控制
• 面向报文，应用层传下来的不合并也不拆分，只是添加udp首部
• 支持一对一、多对一、一对多的交互通信
• 首部8个字节
  

面试常考题

1、TCP三次握手

设A为客户端，B为服务器端

1. B处于LISTEN状态，等待客户的连接请求
2. A发送请求报文，SYN=1,ACK=0，设置一个确认号seq=x。A进入SYN-SENT同步已发送状态
3. B接受报文后，如果同意建立连接，则向A发送连接确认报文，SYN=1,ACK=1,seq=y，确认号ack=x+1。B进入了SYN-RCVD（同步收到）状态
4. A收到B的连接确认报文后，还要向B发出确认，确认号为ack=y+1，seq=x+1。A进入ESTABLISHED（已建立连接）状态
5. B收到A的确认后，连接建立，B进入ESTABLISHED状态，可以通信

2、为什么要3次握手

主要防止已经失效的连接请求报文突然又传送到了服务器，让服务器错误打开连接，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

3、TCP的四次挥手

1. A发送连接释放报文，FIN=1，seq=u。（此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。）
2. B收到之后发出确认ACK=1，seq=v，ack=u+1，此时TCP属于半关闭状态，B能向A发送数据但是A不能向B发送数据。（服务端就进入了CLOSE-WAIT（关闭等待）状态）
3. 当B不再需要连接时，发送释放报文FIN=1,ACK=1,seq=w，ack=u+1。服务器就进入了LAST-ACK（最后确认）状态
4. A收到后发出确认，ACK=1,seq=u+1，ack=w+1，进入TIME-WAIT状态，等待2MSL（最大报文存活时间）后释放连接
5. B收到A的确认报文后释放连接

4、为什么客户端最后还要等待2MSL？

1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
2. 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

5、为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

6、如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

7、TCP如何保证可靠传输

1. 通过超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么重传这个报文段。
2. 数据校验
3. 流量控制
   简单来说就是接收方处理不过来的时候，就把窗口缩小，并把窗口值告诉发送端
   
4. 拥塞控制
   慢开始和拥塞避免
   
   快重传和快恢复
   
   实现方法：滑动窗口
   发送端希望在收到确认前，继续发送其它报文段。
   
   
   (来自https://www.cnblogs.com/huajiezh/p/6593425.html)
   接受窗口只会对窗口内最后一个按序到达的字节进行确认.

   8、使用TCP和UDP的协议

   TCP：HTTP/SMTP/FTP/IMAP/HTTP/TELNET/POP3/SNMP
   UDP：DNS/DHCP/