一、什么是TCP/IP和UDP
- TCP/IP即传输控制/网络协议，是面向连接的协议，发送数据前要先建立连接(发送方和接收方的成对的两个之间必须建 立连接)，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达
- UDP它是属于TCP/IP协议族中的一种。是无连接的协议，发送数据前不需要建立连接，是没有可靠性的协议。因为不需要建立连接所以可以在在网络上以任何可能的路径传输，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。
传统上来说 TCP/IP 被认为是一个四层协议
- 网络接口层:
- 主要是指物理层次的一些接口,比如电缆等。
- 网络层:
- 提供独立于硬件的逻辑寻址,实现物理地址与逻辑地址的转换．
- 在 TCP / IP 协议族中，网络层协议包括 IP 协议（网际协议），ICMP 协议（ Internet 互联网控制报文协议），以及 IGMP 协议（ Internet 组管理协议）.
- 传输层:
- 为网络提供了流量控制,错误控制和确认服务.
- 在 TCP / IP 协议族中有两个互不相同的传输协议： TCP（传输控制协议）和 UDP（用户数据报协议）.
- 应用层:
- 为网络排错,文件传输,远程控制和 Internet 操作提供具体的应用程序
二、TCP和UDP的区别
- TCP是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达；
- UDP是无连接的协议，发送数据前不需要建立连接，是没有可靠性；
- TCP通信类似于于要打个电话，接通了，确认身份后，才开始进行通行；
- UDP通信类似于学校广播，靠着广播播报直接进行通信。
- TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
- TCP是面向字节流的，UDP是面向报文的；
- 面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。
- TCP首部开销（20字节）比UDP首部开销（8字节）要大
- UDP 的主机不需要维持复杂的连接状态表
三、TCP和UDP的应用场景
对某些实时性要求比较高的情况使用UDP，比如游戏，媒体通信，实时直播，即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失的情况
四、TCP三次握手
4.1、什么是TCP的三次握手
在网络数据传输中，传输层协议TCP是要建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手。
4.2、三次握手的具体细节
- 从最开始双方都处于CLOSED状态。然后服务端开始监听某个端口，进入了LISTEN状态。
- 然后客户端主动发起连接，发送 SYN , 自己变成了SYN-SENT状态。
- 服务端接收到，返回SYN和ACK(对应客户端发来的SYN)，自己变成了SYN-REVD。
- 之后客户端再发送ACK给服务端，自己变成了ESTABLISHED状态；服务端收到ACK之后，也变成了ESTABLISHED状态。
- 另外需要提醒你注意的是，从图中可以看出，SYN 是需要消耗一个序列号的，下次发送对应的 ACK 序列号要加1，为什么呢？只需要记住一个规则:
- 凡是需要对端确认的，一定消耗TCP报文的序列号。
- SYN 需要对端的确认， 而 ACK 并不需要，因此 SYN 消耗一个序列号而 ACK 不需要。
4.3、为什么不是两次？
根本原因: 无法确认客户端的接收能力。
分析如下:
如果是两次，你现在发了 SYN 报文想握手，但是这个包滞留在了当前的网络中迟迟没有到达，TCP 以为这是丢了包，于是重传，两次握手建立好了连接。
看似没有问题，但是连接关闭后，如果这个滞留在网路中的包到达了服务端呢？这时候由于是两次握手，服务端只要接收到然后发送相应的数据包，就默认建立连接，但是现在客户端已经断开了。
看到问题的吧，这就带来了连接资源的浪费。
4.4、为什么不是四次？
三次握手的目的是确认双方发送和接收的能力，那四次握手可以嘛？
当然可以，100 次都可以。但为了解决问题，三次就足够了，再多用处就不大了。
4.5、三次握手过程中可以携带数据么？
第三次握手的时候，可以携带。前两次握手不能携带数据。
如果前两次握手能够携带数据，那么一旦有人想攻击服务器，那么他只需要在第一次握手中的 SYN 报文中放大量数据，那么服务器势必会消耗更多的时间和内存空间去处理这些数据，增大了服务器被攻击的风险。
第三次握手的时候，客户端已经处于ESTABLISHED状态，并且已经能够确认服务器的接收、发送能力正常，这个时候相对安全了，可以携带数据。
4.6、同时打开会怎样？
- 在发送方给接收方发SYN报文的同时，接收方也给发送方发SYN报文，两个人刚上了!
- 发完SYN，两者的状态都变为SYN-SENT。
- 在各自收到对方的SYN后，两者状态都变为SYN-REVD。
- 接着会回复对应的ACK + SYN，这个报文在对方接收之后，两者状态一起变为ESTABLISHED。
- 这就是同时打开情况下的状态变迁。
五、 TCP四次挥手
5.1、什么是TCP的四次挥手
在网络数据传输中，传输层协议断开连接的过程我们称为四次挥手
5.2、四次挥手的具体细节
- 发送后客户端变成了FIN-WAIT-1状态。注意, 这时候客户端同时也变成了half-close(半关闭)状态，即无法向服务端发送报文，只能接收。
- 服务端接收后向客户端确认，变成了CLOSED-WAIT状态。
- 客户端接收到了服务端的确认，变成了FIN-WAIT2状态。
- 随后，服务端向客户端发送FIN，自己进入LAST-ACK状态，
- 客户端收到服务端发来的FIN后，自己变成了TIME-WAIT状态，然后发送 ACK 给服务端。
- 注意了，这个时候，客户端需要等待足够长的时间，具体来说，是 2 个 MSL(Maximum Segment Lifetime，报文最大生存时间), 在这段时间内如果客户端没有收到服务端的重发请求，那么表示 ACK 成功到达，挥手结束，否则客户端重发 ACK。
5.3、等待2MSL的意义
- 如果不等待会怎样？
- 如果不等待，客户端直接跑路，当服务端还有很多数据包要给客户端发，且还在路上的时候，若客户端的端口此时刚好被新的应用占用，那么就接收到了无用数据包，造成数据包混乱。所以，最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。
- 那，照这样说一个 MSL 不就不够了吗，为什么要等待 2 MSL?
- 1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
- 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达
- 这就是等待 2MSL 的意义。
5.4、为什么是四次挥手而不是三次？
因为服务端在接收到FIN, 往往不会立即返回FIN, 必须等到服务端所有的报文都发送完毕了，才能发FIN。因此先发一个ACK表示已经收到客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。
如果是三次挥手会有什么问题？
等于说服务端将ACK和FIN的发送合并为一次挥手，这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端，从而让客户端不断的重发FIN。
5.5、同时关闭会怎样？
如果客户端和服务端同时发送 FIN ，状态会如何变化？如图所示:
评论区