TCP/IP协议以及UDP协议

什么是TCP/IP协议?

网络体系结构是分层的体系结构，学术派标准OSI参考模型有七层，而工业标准TCP/IP模型有四层。后者成为了事实上的标准，在介绍时通常分为5层来叙述但应注意TCP/IP模型实际上只有四层。如下图所示：
这里我们将TCP/IP分为5层介绍，越靠下越接近硬件。

物理层
该层负责 比特流在节点之间的传输，即负责物理传输，这一层的协议既与链路有关，也与传输的介质有关。简单来说就是把计算机连接起来的物理手段。

数据链路层
控制网络层与物理层之间的通信，主要功能是保证物理线路上进行可靠的数据传递。为了保证传输，从网络层接收到的数据被分割成特定的可被物理层传输的帧。帧是用来移动数据结构的结构包，他不仅包含原始数据，还包含发送方和接收方的物理地址以及纠错和控制信息。其中的地址确定了帧将发送到何处，而纠错和控制信息则确保帧无差错到达。如果在传达数据时，接收点检测到所传数据中有差错，就要通知发送方重发这一帧。

网络层
决定如何将数据从发送方路由到接收方。网络层通过综合考虑发送优先权，网络拥塞程度，服务质量以及可选路由的花费等来决定从网络中的A节点到B节点的最佳途径。即建立主机到主机的通信。

传输层
该层为两台主机上的应用程序提供端到端的通信。传输层有两个传输协议：TCP(传输控制协议)和 UDP(用户数据报协议)。其中，TCP是一个可靠的面向连接的协议，udp是不可靠的或者说无连接的协议

应用层
应用程序收到传输层的数据后，接下来就要进行解读。解读必须事先规定好格式，而应用层就是规定应用程序的数据格式。主要的协议有：HTTP.FTP,Telent等。

TCP的三次握手

简单理解：
第一次握手： A给B打电话说，你可以听到我说话吗？
第二次握手： B收到了A的信息，然后对A说： 我可以听得到你说话啊，你能听得到我说话吗？
第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！
在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。
这样，就可以开始正常通信了，如果是两次，那将无法确定。
总结：通信双方全都有来有回

TCP 的三次握手除了建立连接外，主要还是为了沟通 TCP 包的序号问题。
例如上面的例子中A 告诉 B，我发起的包的序号是从哪个号开始的，B 同样也告诉 A，B 发起的 包的序号是从哪个号开始的。

过程如图所示：

刚开始的时候，客户端和服务器都处于 CLOSED 状态，先是服务端主动监听某个端口，处于 LISTEN 状态。
第一次握手：客户端主动发起连接 SYN(标记位)，之后处于 SYN-SENT （请求连接）状态。
第二次握手：服务端接收了发起的连接，返回 SYN，并且 ACK ( 确认 ) 客户端的 SYN，之后处于 SYN-SENT 状态。
第三次握手：客户端接收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，之后就处于 ESTAVLISHED 状态。服务端收到 ACK 的 ACK 之后，也处于 ESTABLISHED 状态。
对于客户端来说它发出请求，并收到了服务器的响应，对于服务器来说它响应了客户端的请求，并且也接收到了响应。

问题：为什么要是三次握手？

答：为了防止已失效的连接请求报文突然又传送到了服务端，因为产生错误。
---------谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段” 的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”

TCP 四次挥手

男女分手：
女：我要走了！
男：你真的要走了？
此时，只是女生想分手，即不再发送“数据”，但是男生可能还有未发送完的“数据”，所以需要等待男生也主动关闭。
男：好吧，祝你幸福！
女：谢谢，你也是！

这样整个分手过程就结束了，当然上面只是正常分手的状态，也有些非正常的状态（比如女生说转头就走不再理会男生，男生的祝福得不到女生的回答，不知道该怎么办或则男生开始直接不理会女生，导致女生不知道该怎么办），TCP 协议专门设计了几个状态来处理这些非正常状态。

断开的时候，当女生说分手后，就进入 FIN_WAIT_1 的状态，男生收到女生分手的消息后，进入 CLOSE_WAIT 的状态。

女生收到男生的祝福后，就进入 FIN_WAIT_2 的状态，如果男生直接不理会，则女生永远处与这个状态（太惨了吧）。TCP 协议里面并没有对这个状态的处理，但 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。

如果男生理会并且祝福女生，女生接收到男生的祝福请求之后，从 FIN_WAIT_2 状态结束，按说女生阔以直接走了，但是如果男生没有接收到女生离开的 ACK 呢，就再也接收不到了，所以这时候女生需要等待一段时间，因为如果男生没接收到女生的 ACK 的话会重新发送给女生，所以女生的等待时间需要足够长。

下面再来看看完整过程

第一次挥手
客户端设置seq和 ACK ,向服务器发送一个 FIN(终结)报文段。此时，客户端进入 FIN_WAIT_1 状态，表示客户端没有数据要发送给服务端了。
第二次挥手
服务端收到了客户端发送的 FIN 报文段，向客户端回了一个 ACK 报文段。
第三次挥手
服务端向客户端发送FIN 报文段，请求关闭连接，同时服务端进入 LAST_ACK 状态。
第四次挥手
客户端收到服务端发送的 FIN 报文段后，向服务端发送 ACK 报文段,然后客户端进入 TIME_WAIT 状态。服务端收到客户端的 ACK 报文段以后，就关闭连接。此时，客户端等待 2MSL（指一个片段在网络中最大的存活时间）后依然没有收到回复，则说明服务端已经正常关闭，这样客户端就可以关闭连接了。

UDP协议

UDP 除了端口号，基本啥都没有了。如果没有这两个端口号，数据就不知道该发给哪个应用。所以 UDP 特别简单，有如下三个特点：

简单。不需要大量的数据结构，处理逻辑和包头字段。

天真。它不会建立连接，但是会监听这个地方，谁都可以传给它数据，它也可以传给任何人数据，甚至可以同时传给多个人数据。

顽固。不会根据网络的情况进行拥塞控制，无论是否丢包，它该怎么发还是怎么发

应用场景

需要资源少，网络情况稳定的内网，或者对于丢包不敏感的应用，比如 DHCP 就是基于 UDP 协议的。

不需要一对一沟通，建立连接，而是可以广播的应用。因为它不面向连接，所以可以做到一对多，承担广播或者多播的协议。

需要处理速度快，可以容忍丢包，但是即使网络拥塞，也毫不退缩，一往无前的时候

基于 UDP 的几个例子

直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，所以很多直播应用都基于 UDP 实现了自己的视频传输协议

实时游戏。游戏的特点也是实时性比较高，在这种情况下，采用自定义的可靠的 UDP 协议，自定义重传策略，能够把产生的延迟降到最低，减少网络问题对游戏造成的影响

物联网。一方面，物联网领域中断资源少，很可能知识个很小的嵌入式系统，而维护 TCP 协议的代价太大了；另一方面，物联网对实时性的要求也特别高。
比如 Google 旗下的 Nest 简历 Thread Group，推出了物联网通信协议 Thread，就是基于 UDP 协议的

---

TCP 和 UDP 的区别

·TCP 是面向连接的，UDP 是面向无连接的
·UDP程序结构较简单
·TCP 是面向字节流的，UDP 是基于数据报的
·TCP 保证数据正确性，UDP 可能丢包
·TCP 保证数据顺序，UDP 不保证

什么是面向连接，什么是面向无连接

·在相互连通之前，面向连接的协议会先建立连接，如 TCP 有三次握手，而 UDP 不会

TCP 为什么是可靠连接

·通过 TCP 连接传输的数据无差错，不丢失，不重复，且按顺序到达。
·TCP 报文头里面的序号能使 TCP 的数据按序到达
·报文头里面的确认序号能保证不丢包，累计确认及超时重传机制
·TCP 拥有流量控制及拥塞控制的机制