用户数据报协议（User Datagram Protocol，缩写为UDP），又称用户数据报文协议，是一个简单的面向数据报(package-oriented)的传输层协议，正式规范为RFC 768。
创新互联主营雅安网站建设的网络公司,主营网站建设方案,手机APP定制开发,雅安h5小程序开发搭建,雅安网站营销推广欢迎雅安等地区企业咨询
UDP只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。
UDP在IP数据报的头部仅仅加入了复用和数据校验。
由于缺乏可靠性且属于非连接导向协议，UDP应用一般必须允许一定量的丢包、出错和复制粘贴。
1 在接收udp包时，如果接收包时给定的buffer太小的话，就要自己解决粘包问题。
2 udp包的发送和接收不保证一定成功，不保证按正确顺序抵达。
3 如果不允许丢包的情况出现的话，要有重发机制来保证，如：反馈机制确认。
服务端
客户端
socket常用，本文立足同步和异步socket，以及现有的socketserver库。
同步socket一般有利用socket库直接，就可以写出tcp或udp的套接字
socketserver提供的线程或进程方式的socket
利用python 3.5+的asyncio协议，封装一个协程的socket server ，普通的socket客户也可以连接。
服务器端
客户端
为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据
构造报头信息
服务端
客户端
粘包，分包都tcp
tcp为什么会有粘包分包这些情况：
1.服务端处理不过来
2.客户端采用优化纳格尔算法，达到一定字节才发
怎么处理：
1. 客，服双方确定包头规范，根据包头的信息取包长度
2. 客户端发送带上标记位，如\n, 服务端根据标记取包
服务器端
客户端
服务器端
客户端
服务器端
客户端
封装了socket，而且解决了Io阻塞问题
服务端
客户端
客户端
参考：
阻塞socket和非阻塞socket的区别： 1、读操作 对于阻塞的socket,当socket的接收缓冲区中没有数据时，read调用会一直阻塞住，直到有数据到来才返回。当socket缓冲区中的数据量小于期望读取的数据量时，返回实际读取的字节数。
考虑最简单的情况：两台主机之间的通信。这个时候只需要一条网线把两者连起来，规定好彼此的硬件接口，如都用 USB、电压 10v、频率 2.4GHz 等， 这一层就是物理层，这些规定就是物理层协议 。
我们当然不满足于只有两台电脑连接，因此我们可以使用交换机把多个电脑连接起来，如下图：
这样连接起来的网络，称为局域网，也可以称为以太网（以太网是局域网的一种）。在这个网络中，我们需要标识每个机器，这样才可以指定要和哪个机器通信。这个标识就是硬件地址 MAC。
硬件地址随机器的生产就被确定，永久性唯一。在局域网中，我们需要和另外的机器通信时，只需要知道他的硬件地址，交换机就会把我们的消息发送到对应的机器。
这里我们可以不管底层的网线接口如何发送，把物理层抽离，在他之上创建一个新的层次，这就是 数据链路层 。
我们依然不满足于局域网的规模，需要把所有的局域网联系起来，这个时候就需要用到路由器来连接两个局域网：
但是如果我们还是使用硬件地址来作为通信对象的唯一标识，那么当网络规模越来越大，需要记住所有机器的硬件地址是不现实的；
同时，一个网络对象可能会频繁更换设备，这个时候硬件地址表维护起来更加复杂。这里使用了一个新的地址来标记一个网络对象： IP 地址 。
通过一个简单的寄信例子来理解 IP 地址。
我住在北京市，我朋友 A 住在上海市，我要给朋友 A 写信：
因此，这里 IP 地址就是一个网络接入地址（朋友 A 的住址），我只需要知道目标 IP 地址，路由器就可以把消息给我带到。 在局域网中，就可以动态维护一个 MAC 地址与 IP 地址的映射关系，根据目的 IP 地址就可以寻找到机器的 MAC 地址进行发送 。
这样我们不需管理底层如何去选择机器，我们只需要知道 IP 地址，就可以和我们的目标进行通信。这一层就是 网络层 。网络层的核心作用就是 提供主机之间的逻辑通信 。
这样，在网络中的所有主机，在逻辑上都连接起来了，上层只需要提供目标 IP 地址和数据，网络层就可以把消息发送到对应的主机。
一个主机有多个进程，进程之间进行不同的网络通信，如边和朋友开黑边和女朋友聊微信。我的手机同时和两个不同机器进行通信。
那么当我的手机收到数据时，如何区分是微信的数据，还是王者的数据？那么就必须在网络层之上再添加一层： 运输层 ：
运输层通过 socket（套接字），将网络信息进行进一步的拆分，不同的应用进程可以独立进行网络请求，互不干扰。
这就是运输层的最本质特点： 提供进程之间的逻辑通信 。这里的进程可以是主机之间，也可以是同个主机，所以在 android 中，socket 通信也是进程通信的一种方式。
现在不同的机器上的应用进程之间可以独立通信了，那么我们就可以在计算机网络上开发出形形式式的应用：如 web 网页的 http，文件传输 ftp 等等。这一层称为 应用层 。
应用层还可以进一步拆分出表示层、会话层，但他们的本质特点都没有改变： 完成具体的业务需求 。和下面的四层相比，他们并不是必须的，可以归属到应用层中。
最后对计网分层进行小结：
这里需要注意的是，分层并不是在物理上的分层，而是逻辑上的分层。通过对底层逻辑的封装，使得上层的开发可以直接依赖底层的功能而无需理会具体的实现，简便了开发。
这种分层的思路，也就是责任链设计模式，通过层层封装，把不同的职责独立起来，更加方便开发、维护等等。
TCP 并不是把应用层传输过来的数据直接加上首部然后发送给目标，而是把数据看成一个字节 流，给他们标上序号之后分部分发送。这就是 TCP 的 面向字节流 特性：
面向字节流的好处是无需一次存储过大的数据占用太多内存，坏处是无法知道这些字节代表的意义，例如应用层发送一个音频文件和一个文本文件，对于 TCP 来说就是一串字节流，没有意义可言，这会导致粘包以及拆包问题，后面讲。
前面讲到，TCP 是可靠传输协议，也就是，一个数据交给他，他肯定可以完整无误地发送到目标地址，除非网络炸了。他实现的网络模型如下：
对于应用层来说，他就是一个可靠传输的底层支持服务；而运输层底层采用了网络层的不可靠传输。虽然在网络层甚至数据链路层就可以使用协议来保证数据传输的可靠性，但这样网络的设计会更加复杂、效率会随之降低。把数据传输的可靠性保证放在运输层，会更加合适。
可靠传输原理的重点总结一下有： 滑动窗口、超时重传、累积确认、选择确认、连续 ARQ 。
停止等待协议
要实现可靠传输，最简便的方法就是：我发送一个数据包给你，然后你跟我回复收到，我继续发送下一个数据包。传输模型如下：
这种“一来一去”的方法来保证传输可靠就是 停止等待协议 （stop-and-wait）。不知道还记不记得前面 TCP 首部有一个 ack 字段，当他设置为 1 的时候，表示这个报文是一个确认收到报文。
然后再来考虑另一种情况：丢包。网络环境不可靠，导致每一次发送的数据包可能会丢失，如果机器 A 发送了数据包丢失了，那么机器 B 永远接收不到数据，机器 A 永远在等待。
解决这个问题的方法是： 超时重传 。当机器 A 发出一个数据包时便开始计时，时间到还没收到确认回复，就可以认为是发生了丢包，便再次发送，也就是重传。
但重传会导致另一种问题：如果原先的数据包并没有丢失，只是在网络中待的时间比较久，这个时候机器 B 会受到两个数据包，那么机器 B 是如何辨别这两个数据包是属于同一份数据还是不同的数据？
这就需要前面讲过的方法： 给数据字节进行编号 。这样接收方就可以根据数据的字节编号，得出这些数据是接下来的数据，还是重传的数据。
在 TCP 首部有两个字段：序号和确认号，他们表示发送方数据第一个字节的编号，和接收方期待的下一份数据的第一个字节的编号。
停止等待协议的优点是简单，但缺点是 信道利用率 太低。
假定AB之间有一条直通的信道来传送分组
这里的TD是A发送分组所需要的时间（显然TD = 分组长度 / 数据速率）再假定TA是B发送确认分组所需要的时间（A和B处理分组的时间都忽略不计）那么A在经过TD+RTT+TA时间后才能发送下一个分组，这里的RTT是往返时间，因为只有TD是采用来传输有用的数据（这个数据包括了分组首部，如果可以知道传输更精确的数据的时间，可以计算的更精确），所有信道利用率为
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用 流水线传输 ：就是发送方可以 连续的发送多个分组 ，不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率
停止等待协议已经可以满足可靠传输了，但有一个致命缺点： 效率太低 。发送方发送一个数据包之后便进入等待，这个期间并没有干任何事，浪费了资源。解决的方法是： 连续发送数据包 。
也就是下面介绍的 连续ARQ协议 和 滑动窗口协议
连续 ARQ 协议
模型如下：
和停止等待最大的不同就是，他会源源不断地发送，接收方源源不断收到数据之后，逐一进行确认回复。这样便极大地提高了效率。但同样，带来了一些额外的问题:
发送是否可以无限发送直到把缓冲区所有数据发送完？不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受，那么只是会频繁进行重传，浪费了网络资源。所以发送方发送数据的范围，需要考虑到接收方缓冲区的情况。这就是 TCP 的 流量控制 。
解决方法是： 滑动窗口 。基本模型如下：
在 TCP 的首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的发送窗口大小。通过滑动窗口，就可以实现 TCP 的流量控制，不至于发送太快，导致太多的数据丢失。
连续 ARQ 带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是： 累积确认 。
接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到 4 了，那么发送方就知道 1234 都收到了。
第三个问题是：如何处理丢包情况。在停止等待协议中很简单，直接一个超时重传就解决了。但，连续 ARQ 中不太一样。
例如：接收方收到了 123 567，六个字节，编号为 4 的字节丢失了。按照累积确认的思路，只能发送 3 的确认回复，567 都必须丢掉，因为发送方会进行重传。这就是 GBN（go-back-n) 思路。
但是我们会发现，只需要重传 4 即可，这样不是很浪费资源，所以就有了： 选择确认 SACK 。在 TCP 报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。
第四个问题是：拥塞控制的问题
也是通过窗口的大小来控制的，但是检测网络满不满是个挺难的事情，所以 TCP 发送包经常被比喻成往谁管理灌水，所以拥塞控制就是在不堵塞，不丢包的情况下尽可能的发挥带宽。
水管有粗细，网络有带宽，即每秒钟能发送多少数据；水管有长度，端到端有时延。理想状态下，水管里面的水 = 水管粗细 * 水管长度。对于网络上，通道的容量 = 带宽 * 往返时延。
如果我们设置发送窗口，使得发送但未确认的包为通道的容量，就能撑满整个管道。
如图所示，假设往返时间为 8 秒，去 4 秒，回 4 秒，每秒发送一个包，已经过去了 8 秒，则 8 个包都发出去了，其中前四个已经到达接收端，但是 ACK 还没返回，不能算发送成功，5-8 后四个包还在路上，还没被接收，这个时候，管道正好撑满，在发送端，已发送未确认的 8 个包，正好等于带宽，也即每秒发送一个包，也即每秒发送一个包，乘以来回时间 8 秒。
如果在这个基础上调大窗口，使得单位时间可以发送更多的包，那么会出现接收端处理不过来，多出来的包会被丢弃，这个时候，我们可以增加一个缓存，但是缓存里面的包 4 秒内肯定达不到接收端课，它的缺点会增加时延，如果时延达到一定程度就会超时重传
TCP 拥塞控制主要来避免两种现象，包丢失和超时重传，一旦出现了这些现象说明发送的太快了，要慢一点。
具体的方法就是发送端慢启动，比如倒水，刚开始倒的很慢，渐渐变快。然后设置一个阈值，当超过这个值的时候就要慢下来
慢下来还是在增长，这时候就可能水满则溢，出现拥塞，需要降低倒水的速度，等水慢慢渗下去。
拥塞的一种表现是丢包，需要超时重传，这个时候，采用快速重传算法，将当前速度变为一半。所以速度还是在比较高的值，也没有一夜回到解放前。
到这里关于 TCP 的可靠传输原理就已经介绍得差不多。最后进行一个小结：
当然，这只是可靠传输的冰山一角，感兴趣可以再深入去研究
第一层：应用层，定义了用于在网络中进行通信和传输数据的接口；（Http协议位于该层）
第二层：表示层，定义不同系统中数据的传输格式，编码和解码规范等；
第三层：会话层，管理用户的会话，控制用户间逻辑连接的建立和中断；
第四层：传输层，管理着网络中端到端的数据传输；（Tcp协议位于该层）
第五层：网络层，定义网络设备间如何传输数据；（IP位于该层）
第六层：链路层，将上面的网络层的数据包封装成数据帧，便于物理层传输；
第七层：物理层，这一层主要就是传输这些二进制数据。
建立起一个 TCP 连接需要经过“ 三次握手 ”：
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求。
SYN攻击就是利用三次握手的第二次握手时进行的，这时候服务器处于SYN_RECV状态，等待客户端进行确认ACK，SYN会伪造不存在的源IP，就会有大量的链接处于等待或重试发送SYN+ACK包，导致该阶段队列持续增长，进而导致后续正常请求被丢弃。
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”。
要保持客户端程序的在线状态，需要不断地向服务器发起连接请求，通常情况下即使不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。
而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。
很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。
相关视频推荐
看完《tcp/ip详解》不能coding的，一次课开启设计tcp/ip协议栈
深入聊聊websocket协议，tcp分包与粘包解决方案
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++ Linux服务器架构师学习资料加qun 812855908 获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。
socket则是对TCP/IP协议的封装和应用（程序员层面上）。也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。
关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：
平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，才能使用TCP/IP协议。
实际上，Socket跟TCP/IP协议没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以说，Socket的出现 只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了一些最基本的函数接口，比如create、 listen、connect、accept、send、read和write等等。
实际上，传输层 TCP 是基于网络层 IP 协议的，而应用层 HTTP 协议又是基于传输层 TCP 协议的，而 Socket 本身不算是协议，就像上面所说，它只是提供了一个针对 TCP 或者 UDP 编程的接口。
总结：
Socket 其实并不是一个协议，而是为了方便使用 TCP/UDP 而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。
当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。
WebSocket就像HTTP一样，是一个典型的应用层协议。
总结：
WebSocket是HTML5规范提出的一种协议。HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。
HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。
相同点：
不同点：
联系：
WebSocket连接的过程：
总结：
