udp丢包率高怎么办_HTTP 是基于 TCP 还是 UDP 的？

HTTP只使用TCP传输，从来不会使用UDP传输。   也许绝大多数的读者都知道了这一点，但是类似这样的问题还会不断的涌现。为了更好地科普这个话题，还是要用最简单的语言来进行描述。   UDP UDP的英文是“User Datagram Protocol”, 翻译成“用户数据报协议”。理解这个传输协议，先要真正理解黄色加亮部分的真实含义。通俗地说，就是把用户要发送的完整信息，当做(封装)一封信来邮递。只要用户(HTTP)写好收件人地址(目的IP)、收件人姓名(目的端口)，把信扔进UDP邮筒里，大概率是可以到达收件人的手中的。   但是，万一到达不了怎么办呢？   其实，你没有什么好的办法来判断到还是没到。如果你收到对方的回信，那么信应该到达了。如果没有收到回信，那就代表信没有到达对方手里吗？   不一定吧，也许对方收到你的信，并且回信了，但是回信在返回的路上丢了。比如装信的集装箱掉进海里了。还有可能你的信在去的路上已经丢了，对方压根无法收到。   解决这个问题很好办，用户凭历史经验，一封信往返的时间最多不会超过7天。如果7天依然没有收到对方的回信，那么就默认对方没有收到，再发一封一模一样的信。如果等待14天还没有收到回信，那么就再发一封，再次等待28天。如果多次的尝试依然没有收到回信，那就放弃吧，对方可能被马斯克移民其它星球上去了。  

还有一个问题需要解决，信太厚了无法塞进邮筒，需要用户(HTTP)将厚信分成几封稍薄的信。这需要用户(HTTP)将信进行分装。自然需要在信封上注明“Part 1”、 “Part 2”、 “Part3”。。。，接收方可以按照1、2、3将信拼接成一封完整内容的信。   如果HTTP不介意做以上琐碎的工作，比如超时重传、分装报文、拼接报文，那HTTP用UDP传输并没有什么不好。但很显然HTTP协议的设计者，并不想做这些低级劳动，只想协议简简单单，如果无需记忆任何状态(Stateless)，那是最好不过。   HTTP将这些脏活、累活全部外包(Outsourcing)给第三方，这个第三方的名字叫TCP。   TCP TCP像提供优质服务的快递公司，快递公司尽其所能将信快递到目的地，并不需要用户担心信是否到达，快递公司会实时监控是否到达。另外你也无需担心信是否太厚了。即使你的一封信有100万页都没有关系，快递公司会帮你分装成“Part 1”、 “Part 2”、 “Part 3”。。。   收件方快递公司，会将用户100万页的信按序提交给用户，直到完全到达用户手中。当然快递公司(TCP)所做的工作，远远超出这个文章的描述，流量控制、乱序报文的重新排列、对报文签名(Authentication Option)、使用超大仓库(Scaling Window)存放没有提交的信件Part N、协商集装箱的大小(Maximum Segment Size)、将信件盖上时间戳(Timestamp Option)等等。   当你使用HTTPS的时候，才发现HTTP使用TCP来传输是多么的英明，让我们来看一眼集装箱内包裹的封装方式：   IP / TCP / TLS / HTTP   有了TCP这家提供优质服务的快递公司，不仅HTTP不需要干脏活、累活，连TLS也不需要干底层的脏活，只需要专心提供安全加密就OK了。   如果使用UDP传输呢？不仅HTTP需要干脏活，连带着TLS也需要干脏活，这是多么枯燥、乏味的生活啊！ 更多关于TLS使用UDP传输的细节，欢迎加入会员群讨论！