传输层的保活定时器(三次握手+定时器,主要用于传输层)

Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。 当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。测试结果证实是后者http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP[连接]状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_timeecho 15 > /proc/sys/net/ipv4/tcp_keepalive_intvlecho 5 > /proc/sys/net/ipv4/tcp_keepalive_probeskeepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置idle（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。HTTP 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；HTTP 1.1中默认启用Keep-Alive，如果加入"Connection: close"，才关闭。在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间心跳包很多应用层协议都有HeartBeat机制，通常是客户端每隔一小段时间向服务器发送一个数据包，通知服务器自己仍然在线，并传输一些可能必要的数据。使用心跳包的典型协议是IM，比如QQ/MSN/飞信等协议。心跳包 之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。TCP协议的KeepAlive机制学过TCP/IP的同学应该都知道，传输层的两个主要协议是UDP和TCP，其中UDP是无连接的、面向packet的，而TCP协议是有连接、面向流的协议。所以非常容易理解，使用UDP协议的客户端（例如早期的“OICQ”，听说OICQ.com这两天被抢注了来着，好古老的回忆）需要定时向服务器发送心跳包，告诉服务器自己在线。然而，MSN和现在的QQ往往使用的是TCP连接了，尽管TCP/IP底层提供了可选的KeepAlive（ACK-ACK包）机制，但是它们也还是实现了更高层的心跳包。似乎既浪费流量又浪费CPU，有点莫名其妙。具体查了下，TCP的KeepAlive机制是这样的，首先它貌似默认是不打开的，要用setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开，并且可以设置三个参数tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分别表示连接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方死了、两个ack包之间间隔多长，在我测试的Ubuntu Server 10.04下面默认值是7200秒（2个小时，要不要这么蛋疼啊！）、9次、75秒。于是连接就了有一个超时时间窗口，如果连接之间没有通信，这个时间窗口会逐渐减小，当它减小到零的时候，TCP协议会向对方发一个带有ACK标志的空数据包（KeepAlive探针），对方在收到ACK包以后，如果连接一切正常，应该回复一个ACK；如果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个RST；如果对方没有回复，服务器每隔intvl的时间再发ACK，如果连续probes个包都被无视了，说明连接被断开了。 Ref：

您好 我觉得选B TCP:传输控制协议，可靠传输；UDP是用户数据报协议，不可靠的传输假如仍然不能解决请继续追问。 希望您的问题能尽快解决！谢谢~
我觉得选D应该是吧

TCP协议。POP3，全名为“Post Office Protocol - Version 3”，即“邮局协议版本3”。是TCP/IP协议族中的一员，由RFC1939 定义。本协议主要用于支持使用客户端远程管理在服务器上的电子邮件。提供了SSL加密的POP3协议被称为POP3S。POP 协议支持“离线”邮件处理。其具体过程是：邮件发送到服务器上，电子邮件客户端调用邮件客户机程序以连接服务器，并下载所有未阅读的电子邮件。这种离线访问模式是一种存储转发服务，将邮件从邮件服务器端送到个人终端机器上，一般是PC机或 MAC。一旦邮件发送到 PC 机或MAC上，邮件服务器上的邮件将会被删除。但POP3邮件服务器大都可以“只下载邮件，服务器端并不删除”，也就是改进的POP3协议。扩展资料TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。在数据正确性与合法性上，TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可以使用md5认证对数据进行加密。在保证可靠性上，采用超时重传和捎带确认机制。在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。在拥塞控制上，采用广受好评的TCP拥塞控制算法（也称AIMD算法）。该算法主要包括四个主要部分：（1）慢启动每当建立一个TCP连接时或一个TCP连接发生超时重传后，该连接便进入慢启动阶段。进入慢启动后，TCP实体将拥塞窗口的大小初始化为一个报文段，即：cwnd=1。此后，每收到一个报文段的确认（ACK），cwnd值加1，即拥塞窗口按指数增加。当cwnd值超过慢启动阐值（ssthresh）或发生报文段丢失重传时，慢启动阶段结束。前者进入拥塞避免阶段，后者重新进入慢启动阶段。（2）拥塞避免在慢启阶段，当cwnd值超过慢启动阐值（ssthresh）后，慢启动过程结束，TCP连接进入拥塞避免阶段。在拥塞避免阶段，每一次发送的cwnd个报文段被完全确认后，才将cwnd值加1。在此阶段，cwnd值线性增加。（3）快速重传快速重传是对超时重传的改进。当源端收到对同一个报文的三个重复确认时，就确定一个报文段已经丢失，因此立刻重传丢失的报文段，而不必等到重传定时器（RTO）超时。以此减少不必要的等待时间。（4）快速恢复快速恢复是对丢失恢复机制的改进。在快速重传之后，不经过慢启动过程而直接进入拥塞避免阶段。每当快速重传后，置ssthresh=cwnd/2、ewnd=ssthresh+3。此后，每收到一个重复确认，将cwnd值加1，直至收到对丢失报文段和其后若干报文段的累积确认后，置cwnd=ssthresh，进入拥塞避免阶段。参考资料来源：百度百科-TCP协议参考资料来源：百度百科-POP3
POP3使用的传输层的协议为TCP协议。POP协议适用于C/S结构的脱机模型的电子邮件协议，已发展到第三版，称POP3。脱机模型即不能在线操作，POP不支持对服务器邮件进行扩展操作，此过程需要更高级的IMAP4协议来完成。邮件的传输需要确保可靠，所以说要使用TCP协议。扩展资料：POP3协议的特性1、POP3协议默认端口：1102、POP3协议默认传输协议：TCP3、POP3协议适用的构架结构：C/S4、POP3协议的访问模式：离线访问TCP的主要特点：1、基于流的方式2、面向连接3、可靠通信方式4、在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销。5、通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。TCP通过下列方式来提供可靠性：1、应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段。2、当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。3、TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。4、既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。5、既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。6、TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。参考资料来源：百度百科-POP3参考资料来源：百度百科-TCP
POP3默认的传输协议就是TCP，为了确保传输的信息不丢失，所以是TCP可靠传输。UDP有几率丢包。
POP3，全名为“Post Office Protocol - Version 3”，即“邮局协议版本3”。是TCP/IP协议族中的一员。

当传输大于15字节的上层传输层PDU时，底层传输层就需要对上层传输层PDU进行分包并重新组包为了减少底层传输层包的数量，这里使用块应答机制。问题：怎么通过块应答机制减少底层传输层包的数量？示例中上层传输层访问PDU包含1字节的OPCode字段，3字节的NetKeyIndex和APPKeyIndex字段，还有16字节的APPkey字段。这以为着当使用应用秘钥加密和验证时，上层传输层PDU为24字节。这被底层传输层分为两个包，即分包0和分包1。每个分包具有一个标识分包数的包头，然后被传递到网络层，在那里计算完整的网络层PDU。网络层再使用该网络层PDU的序列号加密网络层PDU，然后对这些消息进行模糊处理，最终只有NID（和IV索引）字节以明文形式可见。因此可以使用两个网络层PDU安全地传递单个访问消息。底层传输层将上层传输层PDU分为一个或多个底层传输层PDU。同一时间底层传输层将同一上层传输层PDU的分包访问消息和分包控制消息发送到同一目的地。只有当上一个传输层PDU的所有分包都已被应答或消息被取消时，底层传输层才可以发送另外一个上层传输层PDU。上层传输层访问消息一个分包最大为12字节，上层传输层控制消息一个分包最大为8字节。因为上层传输层PDU中TransMIC的值是变动的，访问消息是4字节，控制消息是8字节。分包消息会在底层传输层会确认消息，但是不分包消息则不会。为了更加有效可靠的传输上层PDU，应该使用单包分段消息代替未分包消息。因为单包分段消息会被重传，而未分包消息就不会。上层PDU使用SegO字段识别每个分包。用于加密和验证的SeqAuth值将不同分包链接在一起。同一个上层PDU分包后的每个下层传输层PDU应具有相同的IV Index。SeqAuth是一个56bit的值，它由IV Index和第1个分包的序列号组成，其中IV Index在高字节，序列号在低字节。只有低位的13bit（称为SeqZero）才包含在分包消息和分包应答消息中。在对完整的分包消息进行组包时，可以从任何段中的IV Index、SeqZero和SEQ得到SeqAuth值。例如，如果接收到的消息的SEQ是0x647262, IV索引是0x58437AF2，接收到的SeqZero值是0x1849，那么SeqAuth值就是0x58437AF2645849。如果收到的SEQ值为0x647262, SeqZero值为0x1263，则SeqAuth值为0x58437AF2645263。由于SeqZero的大小有限，一旦SEQ比SeqAuth高8192，就不可能发送分段消息。如果一个分段消息在SEQ比SeqAuth高8192时还没有被确认，则取消上行传输PDU的发送。消息的每个段都包括它的段偏移号和最后的段号。段号(SegO)和最后段号(SegN)都包含在消息中，以允许接收方在接收到消息的任何段后总是确定上层传输PDU的大小(到最近的8字节)。当使用了低功耗节点功能时，消息应答由朋友节点执行，而低功耗节点不会发送应答消息。在收到分包消息时，首先应检查SeqAuth以确认此消息是否正在接收或先前是否已接收。如果尚未接收，则接收设备应根据SeqN字段分配足够的内存，以便存储上层传输层PDU的分包并跟踪它的分包是否被收到。如果未使用低功耗功能，则该消息的目的地是单播地址，并且此时节点无法接收此上层传输层PDU，例如因为节点繁忙或资源不足以重新组装此消息，然后节点通过将BlockAck值设置为0x00000000来向源节点发信号，通知它无法接收此上层传输层PDU。底层传输层针对每条收到的某个SeqAuth取值的所有分包消息都设置了序列认证值（Sequence Authentication Value）和块应答值（Block Acknowledgement）。如果底层传输层收到SeqAuth值小于序列认证值的消息分包，则忽略该段。如果底层传输层收到新消息的分包，则它应将该段中的SeqAuth值保存为新的序列认证值。如果底层传输层收到多个分包消息的其中一个分包，但此时因为它当前正忙或没有资源接收更多的分包消息，并且如果该消息的目的地是单播地址，底层传输层应回复一个BlockAck字段为0x00000000的应答消息。当接收SeqAuth值大于序列认证值的一个分包消息时，底层传输层将启动不完成定时器，定义底层传输层接收不同分包的等待最大时间，此定时器应被设置为最少10秒。当接收SeqAuth值大于目的地为单播地址的序列认证值的分包消息时，底层传输层应启动一个应答定时器，该定时器定义底层传输层发送分包应答消息的时间，最少设置为150+50xTTLms.底层传输层应将接收的每个分包在块应答值中进行标记，该块应答值可以稍后传输回源节点。收到分包消息的所有分包之后，底层传输层将发送分包确认消息，其中BlockAck字段被设置为用于序列认证值的块应答值。它应取消未完成定时器和应答定时器，并将重新组装的消息发送到上层传输层。当应答定时器到期时，底层传输层将为当前序列认证值包发送分包应答消息，其中BlockAck字段被设置为块应答值。当未完成定时器到期时，底层传输层应认为正在接收的消息已经失败并取消应答定时器，之前接收的部分消息都应被忽略。如果只看这一篇，会感觉写的太捞了，根本不知道在讲什么玩意，连个例子都没有。没办法，如果没有整个mesh知识体系，举出例子了也没法理解。如果直接上例子，不讲规则，也没法搞。

说明网站使用的是共享虚拟主机，同一台主机上有多个网站
在说清楚什么是域名解析之前，先讲一下为什么要用域名在域名没有被发明之前，人们访问网站都是通过IP地址，也就是类似1.1.1.1这样的一串字符，但是IP地址不直观，而且用户记忆十分不方便，于是人们又发明了另一套字符型的地址方案，即所谓的域名地址域名已经有了，怎么样才能让域名地址和IP地址一一对应呢？这个时候DNS（Domain name server）就出现了，这个应该很多人应该都早有耳闻，域名地址和IP地址的对应关系就放在DNS内，我们只需要记住域名地址就行了，对应转换工作就留给了DNS。回到问题，什么是域名解析？域名解析就是需要我们手动把域名地址和IP地址的对应关系写到DNS服务器上，这样别人访问域名地址的时候就可以在DNS查询到对于的IP地址。我们肯定都遇到过访问一个网站的时候出现错误，找不到IP地址，找不到IP地址一般有下面几个原因。这个域名没有解析我们电脑的DNS有问题有时候域名刚解析，也会出现找不到IP的情况，因为DNS更新需要时间，我们要等一下再试。如何解析域名？我们购买域名之后域名服务商一般都会送DNS解析服务，在解析域名之前我们要知道自己的服务器的地址。我们购买的主机/服务器都会有IP地址或者CANME地址。上面只讲了IP地址，什么是CANME地址呢？CNAME地址看上去其实就是一个域名地址，例如http://hello.youwebcloud.com 这就可以是一个CNAME地址，这个CNAME地址已经解析到一个IP地址1.1.1.1 。当我们把自己的域名解析到CNAME地址http://hello.youwebcloud.com的时候其实就解析到IP地址1.1.1.1为什么要这样做呢？因为有时候主机商提供的IP地址可能会因为网络攻击暂时不可用，为了提高可用性CNAME对应的IP地址可能会变，我们把域名解析到CNAME地址IP地址变化时我们就不需要重新修改域名解析了回到域名解析，这是在优网主机（有永久免费版）购买的网站主机提供的IP地址和CNAME地址（安全起见已经打码）添加两条记录，记录类型CNAME，主机记录分别是www和@记录值是优网主机提供的CNAME地址这样我们的域名就已经解析了，我们上面的操作就相当于在DNS添加了两条记录域名 www.youweb.online 对应我们的 CNAME地址域名 youweb.online 对应我们的 CNAME地址注意：有的域名服务商不允许@主机记录用解析记录类型CNAME，这时候我们应该用A记录类型，记录值填写我们的IP地址我是小优，我是一个要好好努力，让你遇见就爱上的人。从今天开始我要在这个专栏写很多很多文章，主要内容是和大家一起分享一些Web方面的经验，和各位一起探讨更多想法。反正从网站建设到网站运营都会涉及，闲下来时大家吹吹牛B，灌灌水也是可以的。如果这篇文章对你有用的话求赞，求关注。
一、TCP的三次握手？追问：为什么TCP需要握手三次？ **三次握手**1.A向B发送了一个SYN报文表示希望建立连接2.B收到A发过来的数据包后，通过SYN得知这是一个建立连接的请求，于是发送ACK确认，由于TCP的全双工模式，故B向A应该发送一个SYN报文，表示希望和A建立连接。3.A收到B发送来的SYN报文后，A向B发送ACK表示A收到了B的SYN。**追问**1.保证双方都具有接受和发送报文的能力2.防止请求超时导致脏连接因为报文生存时间可能会超过TCP请求超时时间，假如两次握手就可以建立连接，A的报文由于一些问题滞留在网络中，当报文超时但被释放连接后，此超时连接传输到B，B以为是A创建连接的新请求，然后确认连接。但是A知道这是超时连接的，所以直接丢弃了B的确认数据，导致只是B单方面建立了连接。并一直等待A发送数据，B的资源也就浪费了。二、介绍TCP断开的四次挥手？追问为什么TCP的挥手需要四次？**四次挥手**第一步：A向B发送FIN和ACK报文表示希望断开连接第二步：B收到A发送的请求后会发送ACK表示确认断开。第三步：此时B处于半连接状态，B会发送FIN和ACK请求断开与A之间的连接第四步：A收到B发送的断开请求会发送ACK表示确认断开**追问**确保数据能够全部传输完成四次才能保证所有的连接全部断三、为什么连接的时候是三次，挥手的时候是四次？一问： 1、假设连接的时候是两次，那么A滞留在网络中的报文经过一段时间传输到B，B会确认此连接。B单方面建立了连接，A会丢弃B的确认数据报文。B会一直等待A发送数据，造成B资源的浪费。 官方解释： 两次：不能，为了防止已经失效的 2、我们知道三次，双方已经建立了连接，四次完全没有必要二问： 1、确保数据能够全部传输完成 A发送FIN后，B有可能正在向A传输数据，所以不会马上关闭，当数据全部传输完成后再发送ACK表示确认断开。四、TCP的syn攻击的过程？追问：怎么防御？攻击原理B收到SYN报文后，会将相应的半连接记录添加到队列中，之后等待接收握手包，如果握手成功就会将此半连接记录从队列中删除；或者当B未收到A的确认包，会重新发送请求包，直到超时才会将此条记录从半连接队列删除。服务器的TCP协议栈中存储的半连接记录是有限的，当服务器接收到SYN型的DOS攻击后，队列会很快充满，客户端在短时间内伪造大量的不存在的IP地址，向服务器不断发送SYN报文，服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢严重者引起网络堵塞甚至系统瘫痪,服务器随后就不再接受新的网络连接,从而造成正常的客户端无法访问服务器的情况发生。防御1、增大队列SYN最大半连接数，linux中最大连接数为2562、减少半连接时的超时时间3、过滤可疑地址4、利用SYN cookie防御DOS攻击SYN Cookie是用一个Cookie来响应TCPSYN请求的,在正常的TCP连接过程中,当服务器接收一个SYN数据包,就会返回一个SYN-ACK包来应答,半开放连接状态来等待最后返回的ACK包。服务器用一个数据空间来描述所有未解决的连接,然而这个数据空间的大小是有限的,所以攻击者将塞满这个空间,在SYN Cookie的执行过程中,当服务器收到一个SYN包的时候,他返回一个SYN -ACK包,这个数据包的ACK序列号是经过加密的,它由TCP连接的源地址和端口号、目标地址和端口号以及一个加密种子经过HASH计算得出的,然后服务器释放所有的状态。如果一个ACK包从客户端返回后,服务器重新计算Cookie来判断它是不是上个SYN-ACK的返回包。如果是的话,服务器就可以直接进入TCP连接状态并打开连接。这样服务器就可以避免守候半开放连接了五、滑动窗口？ 追问为什么出现滑动窗口滑动窗口用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小。窗口指一次批量发送多少数据。为何出现滑动窗口在确认应答的策略中，每发送一次数据段都需要一个ACK确认应答，收到ACK后再发送下一个数据段，这样每次都需要确认，性能较差。采用滑动窗口的机制就会一次发送多条数据，提高传输性能六、TCP是如何通过滑动窗口协议实现流量控制和拥塞控制的？通过设置滑动窗口的大小，用AVK告知发送端自己缓冲区的大小，从而使发送端以合适的速度发送，实现流量控制；发送端根据网络拥塞情况确定的窗口值。发送端在真正确定发送窗口时，应该取“通知窗口”和“拥塞窗口”的最小值。七、描述TCP和UDP的区别？**UDP**无连接的，即发送数据之前不需要建立连接不保证可靠的交付，同时不使用拥塞控制U支持一对一、一对多、多对一的交互通信首部只有8字节**TCP**面向连接的传输层协议提供可靠的交付能力仅支持一对一通信支持全双工通信首部最低有20字节问题：如何用UDP实现可好传输？引入序列号保证数据的顺序、确认机制保证数据能到达对端、重传机制保证超时引起的数据丢弃。八、TCP有哪些定时器？重传定时器坚持定时器保活定时器时间等待定时器九、什么是CDN，CDN是如何工作的？**一问：**CDN是内容分发网络**二问：**CDN是在用户和服务器之间增加高速缓存层，通过接管DNS实现，将用户的请求引导到高速缓存服务器上获取源服务器的数据十、什么是DNS？说说DNS解析过程？**一问：**DNS为域名系统，是因特网上作为域名和IP地址相互映射的分布式数据库**二问：**1.浏览器检查缓存中有没有这个域名对应的解析过的ip地址，如果有该解析过程将会结束。2.检查本地的hosts文件是否有这个网址映射关系3.如果hosts种没有这个域名映射，查找本地DNS解析器缓存，如果有直接返回4.通过首选DNS服务器(本地域名服务器)，以递归或循环的方式查询域名对应的IP地址并返回。(顶级域，二级域，三级域) 手稿，方面记忆，共勉。