域名解析协议（计算机网络）

UDP特点：无连接，不可靠。面向数据报，发送和接收只能一次完成。有接收缓冲区，没有发送缓冲区（发送方不关心是否接收到）发送的最大数据64k,超过需要在应用层手动分层，多次发送，接收方手动拼装。UDP应用场景：1.面向数据报方式 2.网络数据大多为短消息 3.拥有大量Client 4.对数据安全性无特殊要求 5.网络负担非常重，但对响应速度要求高基于UDP的应用层协议：NFS：网络文件系统
TFTP：简单文件传输协议
DHCP：动态主机配置协议
BOOTP：启动协议
DNS：域名解析协议
复制代码用udp实现可靠传输？传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。
最简单的方式是在应用层模仿传输层TCP的可靠性传输。在不考虑拥塞处理的情况下，可靠UDP的简单设计。
1、添加seq/ack机制，确保数据发送到对端
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制。
复制代码UDP编程的服务器端一般步骤是：　1、创建一个socket，用函数socket()； 　2、设置socket属性，用函数setsockopt();* 可选 　3、绑定IP地址、端口等信息到socket上，用函数bind(); 　4、循环接收数据，用函数recvfrom(); 　5、关闭网络连接；UDP编程的客户端一般步骤是：1、创建一个socket，用函数socket()； 　2、设置socket属性，用函数setsockopt();* 可选 　3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选 　4、设置对方的IP地址和端口等属性; 　5、发送数据，用函数sendto(); 　6、关闭网络连接；【文章福利】小编推荐自己的linuxC/C++语言交流群：832218493，整理了一些个人觉得比较好的学习书籍、视频资料共享在里面，（资料包括C/C++，Linux，golang技术，内核，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）有需要的可以自行添加哦！~!TCPTCP协议格式16位源端口号：16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。16位目的端口号：16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。32位序号：32位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN出现，序列码实际上是初始序列码，而第一个数据字节是ISN+1。这个序列号（序列码）可用来补偿传输中的不一致。32位确认序号：32位的序列号由接收端计算机使用，重组分段的报文成最初形式。如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。4位首部长度：4位包括TCP头大小，指示何处数据开始。保留（6位）：6位值域，这些位必须是0。为了将来定义新的用途而保留。6位标志域表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。6位窗口大小：用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16字节字段，因而窗口大小最大为65535字节。16位校验和：16位TCP头。源机器基于数据内容计算一个数值，j接收信息方要与源机器数值 结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证的。16位紧急指针：指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。选项：长度不定，但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。tcp安全机制确认应答机制经过三次握手建立连接之后，客户端和服务端都进入了数据传输状态。TCP协议需要在不可靠的信道上保证可靠的连接，现在面临的问题：（一包数据可能会被拆成多包发送，如何处理丢包问题；这些数据包到达的先后顺序不同，如何处理乱序问题），针对这些问题，TCP协议建立了一个发送缓冲区，从建立链接后的第一个字节的序列号为0，后面每个字节的序列号就会增加1。发送数据时，从发送缓冲区取一部分数据组成发送报文，在其TCP协议头中会附带序列号和长度，接收端在接收到数据后要回复确认报文，确认报文中的ACK等于接收序列号加长度=下一包的起始序列号，也就是下一包需要发送的起始序列号。这样一问一答的方式能确认使发送端确认发送的数据已经被对方收到。发送端也可以一次性发送连续的多包数据，接收端只需要回复一次ACK就可以了。这样发送端可以把待发送的数据分割成一系列的碎片发送到对端，对端根据序列号和长度在接收后重构出来完整的数据。超时重传机制如上图，如果在传输过程中出现了丢包现象，比如丢包的是100-199，接收端就会给发送方发送ack=100的数据报。接收端就会进行重发补齐。那么如何判定超时呢？受网络带宽的影响，该时间会动态计算得到。设置一个底数时间，每次重发都会将底数翻倍，达到一定次数就会关闭连接！最后，还有一种可能就是重复发送，这个很好解决，通过序列号就可以排除重复数据包！！流量控制通过tcp头部的窗口大小来实现。接收方将自己的缓冲区大小放在窗口大小中，告诉发送端，窗口的字段越大就说明网络的吞吐量越大，发送的速度就越大；如果接收方发现缓冲区的快满了，就将窗口大小的值设置的很小，发送发接收到后就减小发送速度；这样就能实现流量的控制。如果缓冲区满了，窗口大小就直接设置为0；然后发送端收到后就不再发送数据，但是会定期发送窗口探测，以便检测接收方是否能接收数据。拥塞控制发送端会首先发送少量的数据去探测网络拥堵状况，之后会根据实际状况决定发送数据的速度。这里通过拥塞窗口大小来标识发送端的网络状态。tcp连接机制（三次握手，四次挥手）三次握手过程第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。面试题： 为什么要三次握手而不是两次握手？服务端回复完SYN＋ACK之后就建立连接，这是为了防止因为已失效的请求报文，突然又传到服务器而引起错误。假设采用两次握手建立连接，客户端相关服务端发送了一个SYN包请求建立连接，因为某些未知原因，并没有到达服务器，在中间某个网络节点产生了滞留，为了建立连接客户端会重新发送SYN包，这次正常送达，服务端会回复SYN＋ACK，之后建立连接。但第一包数据阻塞的网络节点，突然恢复，第一包SYN包又送达到服务端，这时服务端会认为客户端又发起了一个新的连接，从而在两次握手之后进入等待数据状态，服务端认为是两个连接，而客户端认为是一个连接，造成状态不一致。如果在三次握手的情况下，服务端收不到最后的ACK包，自然不会认为连接建立成功，所以三次握手本质上来说，就是为了解决网络信道不可靠的问题，为了能够在不可靠的信道上建立可靠的连接。面试题：如果连接建立后客户端异常了怎么办？TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。四次挥手过程1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。 2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。 3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。 4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。 5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。 6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。面试题：为什么客户端需要等待超时时间？这是为了保证对方已经收到ACK包，因为假设客户端发送完最后一包ACK包就释放了连接。一旦ACK包在网络中丢失，服务端将一直停留在最后确认状态LAST-ACK。如果客户端发送最后一包ACK包后，等待一段时间，这时服务端因为没有收到ACK包会重发FIN包，客户端会响应这个FIN包，重发ACK包并且刷新超时时间。四次挥手也是为了保证在不可靠的网络链路中进行可靠的连接断开、确认。tcp的效率机制滑动窗口属于TCP协议的一种应用，用于网络数据传输时的流量控制，并发的发送数据报，提高网络的传输速率，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。TCP并不是每一个报文段都会回复ACK的，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送1个ACK【累计ACK】，比如说发送方有1/2/3 3个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上，如果报文1，一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个ACK对这3个报文进行一次确认。其实，我自己都觉得这个图看起来很烦，咋一看，看不懂。我简单的总结一下。这个滑动窗口的机制就是为了并发的发送数据，提高传输效率的。所谓窗口就是指我们一次能并发发送的数据数据报的条数。在这个窗口大小内，我都是并发发送的，不需要等到接收方的ack后才发送。而只有当接收方返回给我一个ack，告诉我下一条发送的数据报序号，我就会根据这个序号滑动对应长度。但是返回的ack往往并不如意，可能在一串数据报中，丢失了一些数据包，接收方本着要得到完成数据包的想法，不管丢的是哪一段，他都会缺失的数据包序号返回给你，而你就能根据发送的序号知道是否数据有丢包，对于一种特殊情况，如果丢失的是中间段的包，接收方就会把后半段未丢失的包也丢失，这样，方便发送方按照自己的ack重传丢失段落后的所有包，不会有重复包。延迟应答接收端接收到数据后可以在避免网络用撒的前提下，延迟自己的应答时间，这样可以让服务端快速消费数据，之后空闲出来的缓冲区更大，返回给接收端的窗口大小就大，这样就能加快传输速率。延迟的机制：可以每隔n个包就ack一次；也可以设置一个延迟应答时间，超过这个时间就ack一次。捎带应答在延时应答的基础上，我们发现，接受方和发送方都是“一发一收”，所以，我们在发送数据的时候，我们把ACK搭顺风车的方式发送给对方了。粘包问题tcp没有不像udp，没有报文长度的记录，只有一个序号，而且udp是一次发，一次读，而tcp是全部写入缓冲区再发；这样对于多段报文之间的开始和结束界限就不是那么明确，所以就需要我们在应用层约定好tcp的数据格式，双方按照既定的格式解析。最后总结一下tcp和udp的区别tcp安全性高，但是效率低；而udp是无连接的，不可靠，但是速度快。tcp是面向字节流，可以多次收发；而udp是面向数据报，只能一次收发tcp连接的双方都具有发送和接收缓冲池，而udp只有接收缓冲池，没有发送缓冲池。tcp发送的数据大小不受限，udp发送数据大小首先，一次最多64k。作者：zero_face链接：https://juejin.cn/post/6992465485476397086来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。