九、UDP 协定
TCP 和 UDP 有哪些区别？
TCP 是面向连贯的，UDP 是面向无连贯的。所谓的建设连贯，是为了在客户端和服务端保护连贯，而建设肯定的数据结构来保护单方交互的状态，用这样的数据结构来保障所谓的面向连贯的个性。
TCP 提供牢靠交付。 通过 TCP 连贯传输的数据，无差错、不失落、不反复、并且按序达到。咱们都晓得 IP 包是没有任何可靠性保障的， 一旦收回去只能事在人为，而 UDP 继承了 IP 包的个性，不保障不失落，不保障按程序达到。
TCP 是面向字节流的。发送的时候发的是一个流，没头没尾。 IP 包可不是一个流，而是一个个的 IP 包。之所以变成了流，这也是 TCP 本人的状态保护做的事件。而 UDP 继承了 IP 的个性，基于数据报的，一个一个地发，一个一个地收。
TCP 是能够有拥塞管制的。 它意识到包抛弃了或者网络的环境不好了，就会依据状况调整本人的行为，看看是不是发快了，要不要发慢点。UDP 就不会，利用让我发，我就发，管它洪水滔天。
因此TCP 其实是一个有状态服务， 艰深地讲就是有脑子的，外面准确地记着发送了没有，接管到没有，发送到哪个了，应该接管哪个了，错一点儿都不行。而 UDP 则是无状态服务。 艰深地说是没脑子的，天真无邪的，收回去就收回去了。
咱们能够这样比喻，如果 MAC 层定义了本地局域网的传输行为，IP 层定义了整个网络端到端的传输行为， 这两层根本定义了这样的基因：网络传输是以包为单位的，二层叫帧，网络层叫包，传输层叫段。 咱们抽象地称为包。包独自传输，自行选路，在不同的设施封装解封装，不保障达到。 基于这个基因，生下来的孩子 UDP 齐全继承了这些个性，简直没有本人的思维。
UDP 包头
发送的时候，我晓得我发的是一个 UDP 的包，收到的那台机器咋晓得的呢？所以在 IP 头外面有个 8 位协定，这里会寄存，数据外面到底是 TCP 还是 UDP，当然这里是 UDP。于是，如果咱们晓得 UDP 头的格局，就能从数据外面，将它解析进去。
当我发送的 UDP 包达到指标机器后，发现 MAC 地址匹配，于是就取下来，将剩下的包传给解决 IP 层的代码。把 IP 头取下来，发现指标 IP 匹配，接下来而后就给传输层解决，解决完后，内核的事件根本就干完了，外面的数据应该交给应用程序本人去解决。
UDP 的三大特点
- 沟通简略，不须要一肚子花花肠子（大量的数据结构、解决逻辑、包头字段）。
- 轻信别人。它不会建设连贯，尽管有端口号，然而监听在这个中央，谁都能够传给他数据，他也能够传给任何人数据，甚至能够同时传给多集体数据。
- 愣头青，做事不懂权变。它不会依据网络的状况进行发包的拥塞管制，无论网络丢包丢成啥样了，它该怎么发还怎么发。
UDP 的三大应用场景
- 须要资源少，在网络状况比拟好的内网，或者对于丢包不敏感的利用。DHCP 就是基于 UDP 协定的。个别的获取 IP 地址都是内网申请，而且一次获取不到 IP 又没事，过一会儿还有机会。
- 不须要一对一沟通，建设连贯，而是能够播送的利用。UDP 的不面向连贯的性能，能够使得能够承载播送或者多播的协定。DHCP 就是一种播送的模式， 就是基于 UDP 协定的，而播送包的格局后面说过了。
- 须要处理速度快，时延低，能够容忍多数丢包，然而要求即使网络拥塞，也毫不退缩，裹足不前的时候。
基于 UDP 的五个例子
网页或者 APP 的拜访
QUIC（全称 Quick UDP Internet Connections，疾速 UDP 互联网连贯）是 Google 提出的一种基于 UDP 改良的通信协议，其目标是升高网络通信的提早，提供更好的用户互动体验。
QUIC 在应用层上，会本人实现疾速连贯建设、缩小重传时延，自适应拥塞管制，
流媒体的协定
直播协定多应用 RTMP。而这个 RTMP 协定也是基于 TCP 的。TCP 的严格程序传输要保障前一个收到了，下一个能力确认，如果前一个收不到，下一个就算包曾经收到了，在缓存外面，也须要等着。对于直播来讲，这显然是不适合的，因为老的视频帧丢了其实也就丢了，就算再传过来用户也不在意了，他们要看新的了，如果老是没来就等着，卡顿了，新的也看不了，那就会失落客户，所以直播，实时性比拟比拟重要，宁肯丢包，也不要卡顿的。
实时游戏
实时游戏中客户端和服务端要建设长连贯，来保障实时传输。然而游戏玩家很多，服务器却不多。因为保护 TCP 连贯须要在内核保护一些数据结构，因此一台机器可能撑持的 TCP 连贯数目是无限的，而后 UDP 因为是没有连贯的，在异步 IO 机制引入之前，经常是应答海量客户端连贯的策略。
另外还是 TCP 的强程序问题，对战的游戏，对网络的要求很简略，玩家通过客户端发送给服务器鼠标和键盘行走的地位，服务器会解决每个用户发送过去的所有场景，解决完再返回给客户端，客户端解析响应，渲染最新的场景展现给玩家。
如果呈现一个数据包失落，所有事件都须要停下来期待这个数据包重发。客户端会呈现期待接收数据，然而玩家并不关怀过期的数据，激战中卡 1 秒，等能动了都曾经死了。
游戏对实时要求较为严格的状况下，采纳自定义的牢靠 UDP 协定，自定义重传策略，可能把丢包产生的提早降到最低，尽量减少网络问题对游戏性造成的影响。
IoT 物联网
一方面，物联网畛域终端资源少， 很可能只是个内存十分小的嵌入式零碎，而保护 TCP 协定代价太大；另一方面，物联网对实时性要求也很高， 而 TCP 还是因为下面的那些起因导致时延大。Google 旗下的 Nest 建设 Thread Group，推出了物联网通信协议 Thread，就是基于 UDP 协定的。
挪动通信畛域
在 4G 网络里，挪动流量上网的数据面对的协定 GTP-U 是基于 UDP 的。因为挪动网络协议比较复杂，而 GTP 协定自身就蕴含简单的手机上线下线的通信协议。如果基于 TCP，TCP 的机制就显得十分多余。
十、TCP 协定
TCP 协定。它之所以这么简单，那是因为它秉承的是“性恶论”。它人造认为网络环境是顽劣的，丢包、乱序、重传，拥塞都是常有的事件，一言不合就可能送达不了，因此要 从算法层面来保障可靠性。
TCP 包头格局
- 包的序号。 为什么要给包编号呢？当然是为了解决乱序的问题。不编好号怎么确认哪个应该先来，哪个应该后到呢。编号是为了解决乱序问题。
- 确认序号。 收回去的包应该有确认，要不然我怎么晓得对方有没有收到呢？如果没有收到就应该从新发送，直到送达。这个能够解决不丢包的问题。
TCP 是靠谱的协定，然而这不能阐明它面临的网络环境好。从 IP 层面来讲，如果网络情况确实那么差，是没有任何可靠性保障的，而作为 IP 的上一层 TCP 也无能为力，惟一能做的就是更加致力，一直重传，通过各种算法保障。也就是说，对于 TCP 来讲，IP 层你丢不丢包，我管不着，然而我在我的层面上，会致力保障可靠性。 - 状态位。 例如 SYN 是发动一个连贯，ACK 是回复，RST 是从新连贯，FIN 是完结连贯等。TCP 是面向连贯的，因此单方要保护连贯的状态，这些带状态位的包的发送，会引起单方的状态变更。
- 窗口大小。 TCP 要做流量管制，通信单方各申明一个窗口，标识本人以后可能的解决能力，别发送的太快，撑死我，也别发的太慢，饿死我。除了做流量管制以外，TCP 还会做拥塞管制，对于真正的通路堵车不堵车，它无能为力，惟一能做的就是管制本人，也即管制发送的速度。
通过对 TCP 头的解析，咱们晓得要把握 TCP 协定，重点应该关注以下几个问题：
程序问题；丢包问题；连贯保护；流量管制；拥塞管制
TCP 的三次握手(连贯保护)
TCP 的连贯建设，咱们经常称为三次握手。
A：您好，我是 A。B：您好 A，我是 B。A：您好 B。咱们也常称为 “申请 -> 应答 -> 应答之应答” 的三个回合。
三次握手除了单方建设连贯外，次要还是为了沟通一件事件，就是 TCP 包的序号的问题。
A 要通知 B，我这面发动的包的序号起始是从哪个号开始的，B 同样也要通知 A，B 发动的包的序号起始是从哪个号开始的。为什么序号不能都从 1 开始呢？因为这样往往会呈现抵触。
这个序号的起始序号是随着工夫变动的，能够看成一个 32 位的计数器，每 4ms 加一，计算一下，如果到反复，须要 4 个多小时，那个绕路的包早就死翘翘了，因为咱们都晓得 IP 包头外面有个 TTL，也即生存工夫。
咱们还是假如这个通路是十分不牢靠的，A 要发动一个连贯，当发了第一个申请石沉大海的时候，会有很多的可能性，比方第一个申请包丢了，再如没有丢，然而绕了弯路，超时了，还有 B 没有响应，不想和我连贯。A 不能确认后果，于是再发，再发。终于，有一个申请包到了 B，然而申请包到了 B 的这个事件，目前 A 还是不晓得的，A 还有可能再发。B 收到了申请包，就晓得了 A 的存在，并且晓得 A 要和它建设连贯。如果 B 不乐意建设连贯，则 A 会重试一阵后放弃，连贯建设失败，没有问题；如果 B 是乐意建设连贯的，则会发送应答包给 A。
当然对于 B 来说，这个应答包也是一入网络深似海，不晓得能不能到达 A。这个时候 B 天然不能认为连贯是建设好了，因为应答包依然会丢，会绕弯路，或者 A 曾经挂了都有可能。而且这个时候 B 还能碰到一个诡异的景象就是，A 和 B 原来建设了连贯，做了简略通信后，完结了连贯。还记得吗？A 建设连贯的时候，申请包反复发了几次，有的申请包绕了一大圈又回来了，B 会认为这也是一个失常的的申请的话，因而建设了连贯，能够设想，这个连贯不会进行上来，也没有个终结的时候，纯属单相思了。因此两次握手必定不行。B 发送的应答可能会发送屡次，然而只有一次达到 A，A 就认为连贯曾经建设了，因为对于 A 来讲，他的音讯有去有回。A 会给 B 发送应答之应答，而 B 也在等这个音讯，能力确认连贯的建设，只有等到了这个音讯，对于 B 来讲，才算它的音讯有去有回。当然 A 发给 B 的应答之应答也会丢，也会绕路，甚至 B 挂了。按理来说，还应该有个应答之应答之应答，这样上来就没底了。所以四次握手是能够的，四十次都能够，要害四百次也不能保障就真的牢靠了。只有单方的音讯都有去有回，就根本能够了。好在大部分状况下，A 和 B 建设了连贯之后，A 会马上发送数据的，一旦 A 发送数据，则很多问题都失去了解决。例如 A 发给 B 的应答丢了，当 A 后续发送的数据达到的时候，B 能够认为这个连贯曾经建设，或者 B 压根就挂了，A 发送的数据，会报错，说 B 不可达，A 就晓得 B 出事件了。当然你能够说 A 比拟坏，就是不发数据，建设连贯后空着。咱们在程序设计的时候，能够要求开启 keepalive 机制，即便没有实在的数据包，也有探活包。另外，你作为服务端 B 的程序设计者，对于 A 这种长时间不发包的客户端，能够被动敞开，从而空出资源来给其余客户端应用。三次握手除了单方建设连贯外，次要还是为了沟通一件事件，就是 TCP 包的序号的问题。A 要通知 B，我这面发动的包的序号起始是从哪个号开始的，B 同样也要通知 A，B 发动的包的序号起始是从哪个号开始的。为什么序号不能都从 1 开始呢？因为这样往往会呈现抵触。例如，A 连上 B 之后，发送了 1、2、3 三个包，然而发送 3 的时候，两头丢了，或者绕路了，于是从新发送，起初 A 掉线了，从新连上 B 后，序号又从 1 开始，而后发送 2，然而压根没想发送 3，然而上次绕路的那个 3 又回来了，发给了 B，B 天然认为，这就是下一个包，于是产生了谬误。因此，每个连贯都要有不同的序号。这个序号的起始序号是随着工夫变动的，能够看成一个 32 位的计数器，每 4ms 加一，如果计算一下，如果到反复，须要 4 个多小时，那个绕路的包早就死翘翘了，因为咱们都晓得 IP 包头外面有个 TTL，也即生存工夫。好了，单方终于建设了信赖，建设了连贯。后面也说过，为了保护这个连贯，单方都要保护一个状态机，在连贯建设的过程中，单方的状态变动时序图就像这样。
一开始，客户端和服务端都处于 CLOSED 状态。先是服务端被动监听某个端口，处于 LISTEN 状态。而后客户端被动发动连贯 SYN，之后处于 SYN-SENT 状态。服务端收到发动的连贯，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。客户端收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收胜利了。服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。
TCP 的四次挥手
A：B 啊，我不想玩了。
B：哦，你不想玩了啊，我晓得了。
这个时候，还只是 A 不想玩了，也即 A 不会再发送数据，然而 B 能不能在 ACK 的时候，间接敞开呢？当然不能够了，很有可能 A 是发完了最初的数据就筹备不玩了，然而 B 还没做完本人的事件，还是能够发送数据的，所以称为半敞开的状态。
这个时候 A 能够抉择不再接收数据了，也能够抉择最初再接管一段数据，期待 B 也被动敞开。
B：A 啊，好吧，我也不玩了，拜拜。
A：好的，拜拜。
这样整个连贯就敞开了。然而这个过程有没有异常情况呢？当然有，下面是战争离别的局面。
A 开始说“不玩了”，B 说“晓得了”，这个回合，是没什么问题的，因为在此之前，单方还处于单干的状态，如果 A 说“不玩了”，没有收到回复，则 A 会从新发送“不玩了”。然而这个回合完结之后，就有可能出现异常状况了，因为曾经有一方率先撕破脸。
一种状况是，A 说完“不玩了”之后，间接跑路，是会有问题的，因为 B 还没有发动完结，而如果 A 跑路，B 就算发动完结，也得不到答复，B 就不晓得该怎么办了。另一种状况是，A 说完“不玩了”，B 间接跑路，也是有问题的，因为 A 不晓得 B 是还有事件要解决，还是过一会儿会发送完结。
断开的时候，咱们能够看到，当 A 说“不玩了”，就进入 FIN_WAIT_1 的状态，B 收到“A 不玩”的音讯后，发送晓得了，就进入 CLOSE_WAIT 的状态。A 收到“B 说晓得了”，就进入 FIN_WAIT_2 的状态，如果这个时候 B 间接跑路，则 A 将永远在这个状态。TCP 协定外面并没有对这个状态的解决，然而 Linux 有，能够调整 tcp_fin_timeout 这个参数，设置一个超时工夫。
如果 B 没有跑路，发送了“B 也不玩了”的申请达到 A 时，A 发送“晓得 B 也不玩了”的 ACK 后，从 FIN_WAIT_2 状态完结，按说 A 能够跑路了，然而最初的这个 ACK 万一 B 收不到呢？则 B 会从新发一个“B 不玩了”，这个时候 A 曾经跑路了的话，B 就再也收不到 ACK 了，因此 TCP 协定要求 A 最初期待一段时间 TIME_WAIT，这个工夫要足够长，长到如果 B 没收到 ACK 的话，“B 说不玩了”会重发的，A 会从新发一个 ACK 并且足够工夫达到 B。A 间接跑路还有一个问题是，A 的端口就间接空进去了，然而 B 不晓得，B 原来发过的很多包很可能还在路上，如果 A 的端口被一个新的利用占用了，这个新的利用会收到上个连贯中 B 发过来的包，尽管序列号是从新生成的，然而这里要上一个双保险，避免产生凌乱，因此也须要等足够长的工夫，等到原来 B 发送的所有的包都死翘翘，再空出端口来。期待的工夫设为 2MSL，MSL 是 Maximum Segment Lifetime，报文最大生存工夫，它是任何报文在网络上存在的最长工夫，超过这个工夫报文将被抛弃。因为 TCP 报文基于是 IP 协定的，而 IP 头中有一个 TTL 域，是 IP 数据报能够通过的最大路由数，每通过一个解决他的路由器此值就减 1，当此值为 0 则数据报将被抛弃，同时发送 ICMP 报文告诉源主机。协定规定 MSL 为 2 分钟，理论利用中罕用的是 30 秒，1 分钟和 2 分钟等。还有一个异常情况就是，B 超过了 2MSL 的工夫，仍然没有收到它发的 FIN 的 ACK，怎么办呢？依照 TCP 的原理，B 当然还会重发 FIN，这个时候 A 再收到这个包之后，A 就示意，我曾经在这里等了这么长时间了，曾经惨绝人寰了，之后的我就都不认了，于是就间接发送 RST，B 就晓得 A 早就跑了。
TCP 状态机
将连贯建设和连贯断开的两个时序状态图综合起来，就是这个驰名的 TCP 的状态机。
如何实现一个靠谱的协定？
程序问题与丢包问题
流量管制问题
拥塞管制问题
十一、套接字 Socket
基于 TCP 和 UDP 协定的 Socket 编程。
Socket 编程进行的是端到端的通信，往往意识不到两头通过多少局域网，多少路由器，因此可能设置的参数，也只能是端到端协定之上网络层和传输层的。
在网络层，Socket 函数须要指定到底是 IPv4 还是 IPv6，别离对应设置为 AF_INET 和 AF_INET6。另外，还要指定到底是 TCP 还是 UDP。还记得咱们后面讲过的，TCP 协定是基于数据流的，所以设置为 SOCK_STREAM，而 UDP 是基于数据报的，因此设置为 SOCK_DGRAM。