面试官问你 TCP/IP 协议了吗？
久违的原创，哈哈，最近太难了，有空跟大家闲聊一下。
TCP/IP 协议族
通常我说 TCP/IP 是指 TCP/IP 协议族。它是基于 TCP 和 IP 这两个最初的协议之上的不同的通信协议的大集合。
例如：http、https、ftp、icmp、arp、rarp、smtp（简单邮件传输协议）
一个网络请求是怎么传输的？
我们拿访问浏览器举个栗子，如图所示：
TCP、UDP有什么区别？各有什么优劣？
TCP 面向连接，提供可靠交付。通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。相对 UDP 开销大
UDP 面向无连接，不保证可靠交付。无拥塞控制，支持一对一、一对多、多对多，开销小。
关于 TCP 协议
确认 ACK - ACKnowledgement 仅当ACK = 1 时，确认才有效。简单来说，就是确认收到数据。
复位 RST - ReSet 标明 TCP 出现严重差错时，必须释放连接，重新建立连接。
同步 SYN - SYNchronization 在建立连接时，用来同步序号。当 SYN = 1，ACK = 0 时，表名这是一个连接请求报文。SYN = 1，ACK = 1 表示这是一个同意请求报文。
终止 FNI - FINis（表示终、完）用来释放连接。当 FNI = 1 表示此段报文发送方已发送完毕。
关于 UDP 协议
解释三次握手
确认号 ack 期望收到对方下一个报文的序列号
序列号 seq
SYN = 1 请求同步序列号，A 的序列号为：x
SYN = 1 ACK = 1，表示确认请求。B 发送的数据的序列号为：y，期望收到 下一个 A 的数据的序列号为：x + 1
ACK = 1 ，表示确认请求。A 发送的数据的序列号为：x + 1，期望收到下一个 B 的数据的序列号为：y + 1
说说TCP三次握手？为什么不两次？
如果发送两次就可以建立连接话，那么只要客户端发送一个连接请求，服务端接收到并发送了确认，就会建立一个连接。
可能出现的问题：如果一个连接请求在网络中跑的慢，超时了，这时客户端会从发请求，但是这个跑的慢的请求最后还是跑到了，然后服务端就接收了两个连接请求，然后全部回应就会创建两个连接，浪费资源！
如果加了第三次客户端确认，客户端在接受到一个服务端连接确认请求后，后面再接收到的连接确认请求就可以抛弃不管了。
说说TCP四次挥手？为什么不是三次？
据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。
第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。
什么是拥塞控制？
简单来说，就是通过网络的拥塞情况来调整 TCP 发送端发送的数据量。发送量先由 1 指数级递增，到一定量时（65535 个字节）开始慢下来，这个时候还是递增的。等到开始丢包时，又开始降低发送速度。
什么是流量控制？
简单来说，就是 TCP 的接受端处理不过来，让 TCP 的发送端发送慢一点。接收端会维护一个处理窗口，即是接收端所能处理数据的能力。接收端将这个处理能力不断反馈给发送端，以此来让发送端调整发送的数据量的多少。