1.TCP(Transmission Control Protocol)
- TCP提供一种面向连接的、可靠的字节流服务。
- 在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP
- TCP使用校验和，确认和重传机制来保证可靠传输
- TCP给数据分节进行排序，并使用累计确认保证数据的顺序不变和非重复
- TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制
- TCP提供全双工通信。（发送缓存和接收缓存）
注意：TCP 并不能保证数据一定会被对方接收到，因为这是不可能的。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说 TCP 也不是 100% 可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知。
2. TCP数据报文格式
比较重要的几个点，都是三次握手/四次挥手中会用到的：
- 32位序号： 在 SYN flag 置 1 时，此为当前连接的初始序列号（Initial Sequence Number, ISN）。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，此字段代表要发送的第一个字节的序号。
- 32位确认序号： ACK flag 置 1 时才有效，期望收到对方下一报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确接收
- 6个标志位： 其中ACK、FIN、SYN标志位会在三次握手/四次挥手中用到。
- 16位窗口大小：这里指的就是滑动窗口
- 4位首部长度：4bits，单位为4字节。确定首部长度，然后确认数据段是从哪开始的。
3. 三次握手
所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。
三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。在 socket 编程中，客户端执行 connect() 时。将触发三次握手。
- 第一次握手(SYN=1, seq=x):
客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。
发送完毕后，客户端进入 SYN_SEND 状态。 - 第二次握手(SYN=1, ACK=1, seq=y, ack=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN（初始序号） 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。 - 第三次握手(ACK=1，ack=y+1)
客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。
三次握手的过程的示意图如下：
4. 四次挥手
- 第一次挥手(FIN=1，seq=x)
假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。发送完毕后，客户端进入 FIN_WAIT_1 状态。 - 第二次挥手(ACK=1，ACKnum=x+1)
服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。 - 第三次挥手(FIN=1，seq=y)服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。
- 第四次挥手(ACK=1，ACKnum=y+1)
客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。
5. UDP（User Datagram Protocol）
16位UDP长度指：指首部字段+数据字段的长度
- UDP是一个非连接的协议，传输数据之前源端和终端不建立连接， 当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、 计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
- 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等， 因此一台服务机可同时向多个客户机传输相同的消息，并且低延时。
- UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。
- 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、 源端和终端主机性能的限制。
- UDP使用尽最大努力交付，即不保证可靠交付， 因此主机不需要维持复杂的链接状态表（这里面有许多参数）。
- UDP是面向报文的。发送方的UDP对应用程序交下来的报文， 在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。
6.TCP与UDP的对比总结
| UDP | TCP |
|---|---|
| 无连接，减少开销和时延 | 面向连接 |
| 支持一对一、一对多、多对一 、多对多的交互通信 | 每一条TCP连接只能有两个端点EP，只能是一对一通信 |
| 对应用层交付的报文添加首部后，直接打包 （面向报文） | 面向字节流 |
| 尽最大努力交付，也就是不可靠；不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
TCP一般用于文件传输（FTP、HTTP对数据准确性要求高，速度可以相对慢），发送或接收邮件（SMTP，对数据准确性要求高），远程登录（对数据准确性有一点高要求，有连接概念）
UDP适用于实时应用。用于即时通信（QQ、微信等对数据准确性和丢包要求比较低，但速度必须快），在线视频（保证视频连续，偶尔花了一个图像帧，人们还是能接受的），网络语音电话（需要高速发送，偶尔断音或串音也没问题）
7. 总结
文章总结了常见的UDP/TCP的面试问题，都是一些概念性的东西。TCP协议本身也会有不足，例如：粘包和拆包现象。这因为这些不足，所以针对性的在TCP协议之上发展出了其他的一些专用协议。
了解TCP/UDP协议，要从底层开始了解，对于许多协议来说，TCP/UDP是其基础，所以学好TCP协议对很多其他协议很有帮助。
