安徽鑫华建设有限公司网站,沪尚茗居全包价格,建一个门户网站要多少钱,建一个做笔记的网站1. 计算机网络的各层协议及作用#xff1f;
计算机网络体系可以大致分为一下三种#xff0c;OSI 七层模型、TCP/IP 四层模型和五层模型。
OSI 七层模型#xff1a;大而全#xff0c;但是比较复杂、而且是先有了理论模型#xff0c;没有实际应用。TCP/IP 四层模型#x…1. 计算机网络的各层协议及作用
计算机网络体系可以大致分为一下三种OSI 七层模型、TCP/IP 四层模型和五层模型。
OSI 七层模型大而全但是比较复杂、而且是先有了理论模型没有实际应用。TCP/IP 四层模型是由实际应用发展总结出来的从实质上讲TCP/IP 只有最上面三层最下面一层没有什么具体内容TCP/IP 参考模型没有真正描述这一层的实现。TCP/IP 五层模型五层模型只出现在计算机网络教学过程中这是对七层模型和四层模型的一个折中既简洁又能将概念阐述清楚。 七层网络体系结构各层的主要功能 应用层为应用程序提供交互服务。在互联网中的应用层协议很多如域名系统DNS支持万维网应用的HTTP协议支持电子邮件的SMTP协议等。 表示层主要负责数据格式的转换如加密解密、转换翻译、压缩解压缩等。 会话层负责在网络中的两个节点之间建立、维持和终止通信如服务器验证用户登录便是由会话层完成的。 运输层有时也译为传输层向主机进程提供通用的数据传输服务。该层主要有以下两种协议 TCP提供面向连接的、可靠的数据传输服务UDP提供无连接的、尽最大努力的数据传输服务但不保证数据传输的可靠性。 网络层选择合适的路由和交换结点确保数据及时传送。主要包括 IP 协议。 数据链路层数据链路层通常简称为链路层。将网络层传下来的 IP 数据包组装成帧并在相邻节点的链路上传送帧。 物理层实现相邻节点间比特流的透明传输尽可能屏蔽传输介质和通信手段的差异。
2. TCP和UDP的区别
对比如下
UDPTCP是否连接无连接面向连接是否可靠不可靠传输不使用流量控制和拥塞控制可靠传输使用流量控制和拥塞控制是否有序无序有序消息在传输过程中可能会乱序TCP 会重新排序传输速度快慢连接对象个数支持一对一一对多多对一和多对多交互通信只能是一对一的点对点通信传输方式面向报文面向字节流首部开销首部开销小仅 8 字节首部最小20字节最大60字节适用场景适用于实时应用IP电话、视频会议、直播等适用于要求可靠传输的应用例如文件传输
总结
TCP 用于在传输层有必要实现可靠传输的情况UDP 用于对高速传输和实时性有较高要求的通信。TCP 和 UDP 应该根据应用目的按需使用。
3. UDP 和 TCP 对应的应用场景是什么
TCP 是面向连接能保证数据的可靠性交付因此经常用于
FTP 文件传输HTTP / HTTPS
UDP 面向无连接它可以随时发送数据再加上 UDP 本身的处理既简单又高效因此经常用于
包总量较少的通信如 DNS 、SNMP 等视频、音频等多媒体实时通信广播通信 4. 详细介绍一下 TCP 的三次握手机制
第一次握手客户端发送 SYN 1 seq x 给服务端请求建立连接。SYN 1 表示这是一个TCP连接请求报文seq x 表示客户端进程使用序号 x 作为初始序号。客户端进入 SYN_SENT 状态等待服务器确认第二次握手服务端发送 SYN 1 ACK 1 ack x 1 seq y 给客户端。SYN 1 ACK 1 表示当前报文是对客户端请求的确认报文确认号是 ack x 1 同时选择 seq y 作为初始序号此时服务器进入 SYN_RECV 状态。第三次握手客户端发送 ACK 1 ack y 1 seq x 1 给服务端。ACK 1 表当前报文是对服务端请求的确认报文确认号为 ack y 1序列号为 seq x 1客户端和服务器进入 ESTABLISHED 状态完成三次握手。 理想状态下TCP连接一旦建立在通信双方中的任何一方主动关闭连接之前TCP 连接都将被一直保持下去。
5. 为什么需要三次握手而不是两次
TCP 是可靠的传输控制协议而三次握手是保证数据可靠传输又能提高传输效率的最小次数。
主要有三个原因 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。 第一次握手客户端只是发送处请求报文段什么都无法确认而服务器可以确认自己的接收能力和对方的发送能力正常 第二次握手客户端可以确认自己发送能力和接收能力正常对方发送能力和接收能力正常 第三次握手服务器可以确认自己发送能力和接收能力正常对方发送能力和接收能力正常 可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常这样就可以愉快地进行通信了。 告知对方自己的初始序号值并确认收到对方的初始序号值。 为了实现可靠数据传输 TCP协议的通信双方都必须维护一个序列号和一个确认号字段 以标识发送出去的数据包中哪些是已经被对方收到的。这两个字段的值会在初始序号值的基础上递增。 三次握手的过程即是通信双方相互告知序列号起始值并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手 至多只有连接发起方的起始序列号能够被确认 而另一方选择的序列号则得不到确认。 防止已过期如超时重传的连接请求报文突然又传送到服务器因而产生错误和资源浪费。 如果采用两次握手则第一次请求之后服务端就确认已建立连接那么此时如果客户端关闭连接之后服务端又收到了客户端之前已失效的 TCP 连接请求后向客户端发送确认请求报文此时客户端因为是关闭状态无法响应服务端则服务端会因为不知道客户端已经处于关闭状态还在一直不停的给客户端发送确认请求报文导致浪费资源。
6. 为什么要三次握手而不是四次
因为三次握手已经可以确认双方的发送接收能力正常双方都知道彼此已经准备好而且也可以完成对双方初始序号值得确认也就无需再第四次握手了。
第一次握手服务端确认“自己收、客户端发”报文功能正常。第二次握手客户端确认“自己发、自己收、服务端收、服务端发”报文功能正常客户端认为连接已建立。第三次握手服务端确认“自己发、客户端收”报文功能正常此时双方均建立连接可以正常通信。
7. 什么是 SYN 洪泛攻击如何防范
SYN洪泛攻击属于 DOS 攻击的一种它利用 TCP 协议缺陷通过发送大量的半连接请求耗费 CPU 和内存资源。
原理
在三次握手过程中服务器发送 [SYN/ACK] 包第二个包之后、收到客户端的 [ACK] 包第三个包之前的 TCP 连接称为半连接half-open connect此时服务器处于 SYN_RECV等待客户端响应状态。如果接收到客户端的 [ACK]则 TCP 连接成功如果未接受到则会不断重发请求直至成功。SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址向服务器不断地发送 [SYN] 包服务器回复 [SYN/ACK] 包并等待客户的确认。由于源地址是不存在的服务器需要不断的重发直至超时。这些伪造的 [SYN] 包将长时间占用未连接队列影响了正常的 SYN导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。
检测当在服务器上看到大量的半连接状态时特别是源 IP 地址是随机的基本上可以断定这是一次 SYN 攻击。
防范
通过防火墙、路由器等过滤网关防护。通过加固 TCP/IP 协议栈防范如增加最大半连接数缩短超时时间。SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改专门用来防范 SYN 洪泛攻击的一种手段。
8. 三次握手连接阶段最后一次ACK包丢失会发生什么
服务端 第三次的ACK在网络中丢失那么服务端该 TCP 连接的状态为 SYN_RECV并且会根据 TCP 的超时重传机制会等待3秒、6秒、12秒后重新发送 SYN ACK 包以便客户端重新发送 ACK 包。 如果重发指定次数之后仍然未收到客户端的 ACK 应答那么一段时间后服务端自动关闭这个连接。
客户端
客户端认为这个连接已经建立如果客户端向服务端发送数据服务端将以 RST 包Reset标示复位用于异常的关闭连接响应。此时客户端知道第三次握手失败。
9. 详细介绍一下 TCP 的四次挥手过程 第一次客户端发送 FIN 1 ACK 1 seq u ack v 给服务端。FIN 1 表示这是一个 TCP 释放连接的请求报文。 第二次服务端发送 ACK 1 seq v ack u 1 给客户端。表示确认了客户端第一次的释放连接请求报文。 此时 A → B 方向的连接释放了TCP 处于半关闭状态虽然 B 确认了 A 不会再发送数据了但 B 仍有可能给 A 发送数据。 第三次服务端发送 FIN 1 ACK 1 seq w ack u 1 给客户端表示服务端释放连接的请求报文。 序列号 seq w即服务端上次发送的报文的最后一个字节的序号 1。确认号 ack u 1与第二次挥手相同因为这段时间客户端没有发送数据 第四次客户端发送 ACK 1 seq u 1 ack w 1 给服务端。表示确认了服务端的关闭请求。 此时服务端直接进入关闭状态客户端进入 TIME_WAIT 等待状态等待时长为 2MSL即最长报文生命周期的 2 倍如果这期间没有收到对方的报文客户端才最终进入关闭状态。 可以看到服务端结束 TCP 连接的时间要比客户端早一些。
10. 为什么连接的时候是三次握手关闭的时候却是四次握手 服务器在收到客户端的 FIN 报文段后可能还有一些数据要传输所以不能马上关闭连接但是会做出应答返回 ACK 报文段。 接下来可能会继续发送数据在数据发送完后服务器会向客户单发送 FIN 报文表示数据已经发送完毕请求关闭连接。 服务器的 ACK 和 FIN 一般都会分开发送从而导致多了一次因此一共需要四次挥手。 TCP 是全双工的连接必须两端同时关闭连接连接才算真正关闭。 如果 A 已经准备关闭写但是它还可以读 B 发送来的数据。此时A 发送 FIN 报文给 B 收到后B 回复 ACK 报文给 A。 当 B 也准备关闭写发送 FIN 报文给 AA 回复 ACK 给 B。此时两端都关闭了TCP 连接才正常关闭。 所以对全双工模式来说为了彻底关闭就需要通信两端的 4 次交互才行互相确认对方的关闭状态。
11. 为什么客户端的 TIME-WAIT 状态必须等待 2MSL 保证可靠的终止 TCP 连接。确保 ACK 报文能够到达服务端从而使服务端正常关闭连接。 如果第四次客户端给服务端发送的确认报文丢失了则服务端会因为没有收到确认报文超时重传 FIN/ACK 报文给客户端。 但是如果此时客户端处于关闭状态就会无法响应服务端了那么服务端就会一直在重传 FIN/ACK 报文也就是说服务端一直得不到确认最终会无法进入 CLOSED 状态。 MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间即「客户端 ACK 报文 1MSL 超时 服务端 FIN 报文 1MSL 传输」就能够收到服务端重传的 FIN/ACK 报文然后客户端重传一次 ACK 报文并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。 如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端服务端则会继续超时重试直到断开连接。 防止已失效的连接请求报文段出现在之后的连接中。 TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后再经过时间 2MSL就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文也可以不处理它。
12. 如果已经建立了连接但是客户端出现故障了怎么办
通过定时器 超时重试机制尝试获取确认直到最后会自动断开连接。
具体而言TCP 设有一个保活计时器。服务器每收到一次客户端的数据都会重新复位这个计时器时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据服务器就开始重试每隔 75 秒钟发送一个探测报文段若一连发送 10 个探测报文后客户端依然没有回应那么服务器就认为连接已经断开了。
13. TIME-WAIT 状态过多会产生什么后果怎样处理
从服务器来讲短时间内关闭了大量的Client连接就会造成服务器上出现大量的TIME_WAIT连接严重消耗服务器的资源此时部分客户端就会显示连接不上。
从客户端来讲客户端TIME_WAIT过多就会导致端口资源被占用因为端口就65536个被占满就会导致无法创建新的连接。
解决办法
服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态此套接字选项告诉内核即使此端口正忙处于 TIME_WAIT状态也请继续并重用它。调整系统内核参数修改/etc/sysctl.conf文件即修改net.ipv4.tcp_tw_reuse 和 tcp_timestamps
net.ipv4.tcp_tw_reuse 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接默认为0表示关闭
net.ipv4.tcp_tw_recycle 1 表示开启TCP连接中TIME-WAIT sockets的快速回收默认为0表示关闭。强制关闭发送 RST 包越过 TIME_WAIT 状态直接进入 CLOSED 状态。
14. TIME_WAIT 是服务器端的状态? 还是客户端的状态?
TIME_WAIT 是主动断开连接的一方会进入的状态一般情况下都是客户端所处的状态; 服务器端一般设置不主动关闭连接。
TIME_WAIT 需要等待 2MSL在大量短连接的情况下TIME_WAIT 会太多这也会消耗很多系统资源。对于服务器来说在 HTTP 协议里指定 KeepAlive浏览器重用一个 TCP 连接来处理多个 HTTP 请求由浏览器来主动断开连接可以一定程度上减少服务器的这个问题。
15. TCP协议如何保证可靠性
TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制 和 流量控制等方法实现了可靠性传输。 检验和通过检验和的方式接收端可以检测出来数据是否有差错和异常假如有差错就会直接丢弃TCP段重新发送。 序列号/确认应答 序列号的作用不仅仅是应答的作用有了序列号能够将接收到的数据根据序列号排序并且去掉重复序列号的数据。 TCP传输的过程中每次接收方收到数据后都会对传输方进行确认应答。也就是发送ACK报文这个ACK报文当中带有对应的确认序列号告诉发送方接收到了哪些数据下一次的数据从哪里发。 滑动窗口滑动窗口既提高了报文传输的效率也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。 超时重传超时重传是指发送出去的数据包到接收到确认包之间的时间如果超过了这个时间会被认为是丢包了需要重传。最大超时时间是动态计算的。 拥塞控制在数据传输过程中可能由于网络状态的问题造成网络拥堵此时引入拥塞控制机制在保证TCP可靠性的同时提高性能。 流量控制如果主机A 一直向主机B发送数据不考虑主机B的接受能力则可能导致主机B的接受缓冲区满了而无法再接受数据从而会导致大量的数据丢包引发重传机制。而在重传的过程中若主机B的接收缓冲区情况仍未好转则会将大量的时间浪费在重传数据上降低传送数据的效率。所以引入流量控制机制主机B通过告诉主机A自己接收缓冲区的大小来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。
16. 详细讲一下TCP的滑动窗口
在进行数据传输时如果传输的数据比较大就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后才可以发送下一个数据包。这样一来就会在等待确认应答包环节浪费时间。 为了避免这种情况TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。 从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组滑动窗口右边是还没有轮到的分组。
滑动窗口里面也分为两块一块是已经发送但是未被确认的分组另一块是窗口内等待发送的分组。随着已发送的分组不断被确认窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。
17. 详细讲一下拥塞控制
TCP 一共使用了四种算法来实现拥塞控制
慢开始 (slow-start)拥塞避免 (congestion avoidance)快速重传 (fast retransmit)快速恢复 (fast recovery)
发送方维持一个叫做拥塞窗口cwndcongestion window的状态变量。
当cwndssthresh时使用慢开始算法。当cwndssthresh时改用拥塞避免算法。当cwndssthresh时慢开始与拥塞避免算法任意。
慢开始不要一开始就发送大量的数据由小到大逐渐增加拥塞窗口的大小。
拥塞避免拥塞避免算法让拥塞窗口缓慢增长即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
快重传我们可以剔除一些不必要的拥塞报文提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认而不要等到自己发送数据时捎带确认。快重传规定发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段而不必继续等待设置的重传计时器时间到期。 快恢复主要是配合快重传。当发送方连续收到三个重复确认时就执行“乘法减小”算法把ssthresh门限减半为了预防网络发生拥塞但接下来并不执行慢开始算法因为如果网络出现拥塞的话就不会收到好几个重复的确认收到三个重复确认说明网络状况还可以。 18. HTTP常见的状态码有哪些
常见状态码
200请求被服务器成功处理204请求被受理但没有资源可以返回206客户端只是请求资源的一部分服务器只对请求的部分资源执行 GET方法相应报文中通过 Content-Range 指定范围的资源。301永久性重定向302临时重定向400客户端请求报文有语法错误不能被服务器识别401请求需要认证403请求的对应资源禁止被访问服务器收到请求但是拒绝提供服务。404服务器无法找到对应资源500服务器内部错误服务器遇到错误无法完成请求。503服务器正忙
状态码开头代表类型 19. 状态码301和302的区别是什么
共同点301和302状态码都表示重定向就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址这个地址可以从响应的Location首部中获取用户看到的效果就是他输入的地址A瞬间变成了另一个地址B。
不同点 301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址 302表示旧地址A的资源还在仍然可以访问这个重定向只是临时地从旧地址A跳转到地址B搜索引擎会抓取新的内容而保存旧的网址。 SEO中302好于301。
重定向原因
网站调整如改变网页目录结构网页被移到一个新地址网页扩展名改变(如应用需要把.php改成.Html或.shtml)。
20. HTTP 常用的请求方式 为了方便记忆可以将 PUT、DELETE、POST、GET 理解为客户端对服务端的增删改查。
PUT上传文件向服务器添加数据可以看作增DELETE删除文件POST传输数据向服务器提交数据对服务器数据进行更新。GET获取资源查询服务器资源
21. GET请求和POST请求的区别
使用上的区别
GET使用URL或Cookie传参而POST将数据放在BODY中这个是因为HTTP协议用法的约定。GET方式提交的数据有长度限制则POST的数据则可以非常大这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。POST比GET安全因为数据在地址栏上不可见这个说法没毛病但依然不是GET和POST本身的区别。
本质区别 GET和POST最大的区别主要是GET请求是幂等性的POST请求不是。这个是它们本质区别。 幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。
22. 解释一下HTTP长连接和短连接
在HTTP/1.0中默认使用的是短连接。也就是说浏览器和服务器每进行一次HTTP操作就建立一次 TCP 连接但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源如JavaScript文件、图像文件、CSS文件等当浏览器每遇到这样一个Web资源就会建立一个HTTP会话。
但从 HTTP/1.1起默认使用长连接用以保持连接特性。使用长连接的HTTP协议会在响应头有加入这行代码Connection: keep-alive
在使用长连接的情况下当一个网页打开完成后客户端和服务器之间用于传输HTTP数据的 TCP 连接不会关闭如果客户端再次访问这个服务器上的网页会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接它有一个保持时间可以在不同的服务器软件如Apache中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接实质上是TCP协议的长连接和短连接。
23. HTTP请求报文和响应报文的格式
请求报文格式
请求行请求方法URI协议版本请求头部空行CRLF回车换行请求主体 GET /sample.jsp HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflateusernamejinqiaopassword1234 请求主体响应报文
状态行协议版本状态码原因短语响应头部空行CRLF响应主体 HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112html
head
titleHTTP响应示例title
/head
body
Hello HTTP!
/body
/html24. HTTP 1.0 和 HTTP 1.1 的区别?
HTTP1.0 最早在网页中使用是在 1996 年那个时候只是使用一些较为简单 的网页上和网络请求上而 HTTP1.1 则在 1999 年才开始广泛应用于现在的各大浏览器网络请求中同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议。
主要区别主要体现在
长连接HTTP 1.1 支持长连接和请求的流水线处理在一个TCP连接上可以传送多个HTTP请求和响应减少了建立和关闭连接的消耗和延迟在 HTTP 1.1 中默认开启 Connectionkeep-alive一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。缓存处理在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准HTTP 1.1 则引入了更多的缓存控制策略例如 Entity tag, If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓 存策略。带宽优化及网络连接的使用HTTP1.0中存在一些浪费带宽的现象例如客户端只是需要某个对象的一部分而服务器却将整个对象送过来了并且不支持断点续传功能HTTP1.1则在请求头引入了range头域它允许只请求资源的某个部分即返回码是206Partial Content这样就方便了开发者自由的选择以便于充分利用带宽和连接。错误通知的管理在HTTP1.1中新增了24个错误状态响应码如409Conflict表示请求的资源与资源的当前状态发生冲突410Gone表示服务器上的某个资源被永久性的删除。Host头处理在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址因此请求消息中的URL并没有传递主机名hostname。但随着虚拟主机技术的发展在一台物理服务器上可以存在多个虚拟主机Multi-homed Web Servers并且它们共享一个IP地址。HTTP 1.1 的请求消息和响应消息都应支持 Host 头域且请求消息中如果没有 Host 头域会报告一个错误400 Bad Request。
25. HTTP 1.1 和 HTTP 2.0 的区别
HTTP2.0相比HTTP1.1支持的特性
新的二进制格式HTTP1.1的解析是基于文本。基于文本协议的格式解析存在天然缺陷文本的表现形式有多样性要做到健壮性考虑的场景必然很多二进制则不同只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式实现方便且健壮。多路复用即连接共享即每一个request都是用作连接共享机制的。一个request对应一个id这样一个连接上可以有多个request每个连接的request可以随机的混杂在一起接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。头部压缩HTTP1.1的头部header带有大量信息而且每次都要重复发送HTTP2.0使用encoder来减少需要传输的header大小通讯双方各自cache一份header fields表既避免了重复header的传输又减小了需要传输的大小。服务端推送服务器除了对最初请求的响应外服务器还可以额外的向客户端推送资源而无需客户端明确的请求。
HTTP2.0 的多路复用和 HTTP1.X 中的长连接复用有什么区别
HTTP/1.0 一次请求-响应建立一个连接用完关闭每一个请求都要建立一个连接HTTP/1.1 Pipeling 解决方式为若干个请求排队串行化单线程处理后面的请求等待前面请求的返回才能获得执行机会一旦有某请求超时等后续请求只能被阻塞毫无办法也就是人们常说的队头阻塞HTTP/2 多个请求可同时在一个连接上并行执行。某个请求任务耗时严重不会影响到其它连接的正常执行
26. HTTP 与 HTTPS 的区别 HTTPS 协议HyperText Transfer Protocol over Secure Socket Layer一般理解为 HTTP SSL/TLS通过 SSL 证书来验证服务器的身份并为浏览器和服务器之间的通信进行加密。
HTTP 的 URL 以 http:// 开头而 HTTPS 的 URL 以 https:// 开头HTTP 是不安全的而 HTTPS 是安全的HTTP 标准端口是 80 而 HTTPS 的标准端口是 443在 OSI 网络模型中HTTP 工作于应用层而 HTTPS 的安全传输机制工作在传输层HTTP 无法加密而 HTTPS 对传输的数据进行加密HTTP 无需证书而 HTTPS 需要 CA 机构颁发的 SSL 证书
27. HTTPS 的优缺点?
优点
安全性 使用HTTPS协议可认证用户和服务器确保数据发送到正确的客户机和服务器HTTPS协议是由SSLHTTP协议构建的可进行加密传输、身份认证的网络协议要比http协议安全可防止数据在传输过程中不被窃取、改变确保数据的完整性。HTTPS是现行架构下最安全的解决方案虽然不是绝对安全但它大幅增加了中间人攻击的成本。
SEO方面谷歌曾在2014年8月份调整搜索引擎算法并称“比起同等HTTP网站采用HTTPS加密的网站在搜索结果中的排名将会更高”。
缺点
在相同网络环境中HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。HTTPS 的安全是有范围的在黑客攻击、服务器劫持等情况下几乎起不到作用。在现有的证书机制下中间人攻击依然有可能发生。HTTPS 需要更多的服务器资源也会导致成本的升高。
28. 讲一讲HTTPS 的原理 加密流程按图中的序号分为 ① 客户端请求 HTTPS 网址然后连接到 server 的 443 端口 (HTTPS 默认端口类似于 HTTP 的 80 端口)。 ② 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存不可泄漏。公钥则是附带在证书的信息中可以公开的。证书本身也附带一个证书电子签名这个签名用来验证证书的完整性和真实性可以防止证书被篡改。 ③ 服务器响应客户端请求将证书传递给客户端证书包含公钥和大量其他信息比如证书颁发机构信息公司信息和证书有效期等。 ④ 客户端解析证书并对其进行验证。如果证书不是可信机构颁布或者证书中的域名与实际域名不一致或者证书已经过期就会向访问者显示一个警告由其选择是否还要继续通信。 如果证书没有问题客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY并使用公钥A将其加密。 ⑤ 客户端把加密后的随机码 KEY 发送给服务器作为后面对称加密的密钥。 ⑥ 服务器在收到随机码 KEY 之后会使用私钥B将其解密。 经过以上这些步骤客户端和服务器终于建立了安全连接完美解决了对称加密的密钥泄露问题接下来就可以用对称加密愉快地进行通信了。 ⑦ 服务器使用对称密钥 (随机码 KEY) 对数据进行对称加密并发送给客户端客户端使用相同的密钥 (随机码 KEY) 解密数据。 ⑧ 双方使用对称加密愉快地传输所有数据。
29. 在浏览器中输入www.baidu.com后执行的全部过程 域名解析域名 www.baidu.com 变为 ip 地址。 浏览器搜索自己的DNS缓存维护一张域名与IP的对应表 若没有则搜索操作系统的DNS缓存维护一张域名与IP的对应表 若没有则搜索操作系统的hosts文件维护一张域名与IP的对应表。 若都没有则找 tcp/ip 参数中设置的首选 dns 服务器即本地 dns 服务器递归查询本地域名服务器查询自己的dns缓存如果没有则进行迭代查询。本地dns服务器将IP返回给操作系统同时缓存IP。 发起 tcp 的三次握手建立 tcp 连接。浏览器会以一个随机端口1024-65535向服务端的 web 程序 80 端口发起 tcp 的连接。 建立 tcp 连接后发起 http 请求。 服务器响应 http 请求客户端得到 html 代码。服务器 web 应用程序收到 http 请求后就开始处理请求处理之后就返回给浏览器 html 文件。 浏览器解析 html 代码并请求 html 中的资源。 浏览器对页面进行渲染并呈现给用户。 一般情况下一旦服务器向客户端返回了请求数据它就要关闭 TCP 连接然后如果客户端或者服务器在其头信息加入了这行代码 Connection: keep-alive TCP 连接在发送后将仍然保持打开状态于是客户端可以继续通过相同的连接发送请求也就是说前面的 3 到 6可以反复进行。保持连接节省了为每个请求建立新连接所需的时间还节约了网络带宽。
30. 什么是 Cookie 和 Session ?
什么是 Cookie
HTTP Cookie也叫 Web Cookie或浏览器 Cookie是服务器发送到用户浏览器并保存在本地的一小块数据它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常它用于告知服务端两个请求是否来自同一浏览器如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面
会话状态管理如用户登录状态、购物车、游戏分数或其它需要记录的信息个性化设置如用户自定义设置、主题等浏览器行为跟踪如跟踪分析用户行为等
什么是 Session
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样当用户在应用程序的 Web 页之间跳转时存储在 Session 对象中的变量将不会丢失而是在整个用户会话中一直存在下去。当客户端关闭会话或者 Session 超时失效时会话结束。
31. Cookie 和 Session 是如何配合的呢
用户第一次请求服务器的时候服务器根据用户提交的相关信息创建对应的 Session 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器浏览器接收到服务器返回的 SessionID 信息后会将此信息存入到 Cookie 中同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候请求会自动判断此域名下是否存在 Cookie 信息如果存在自动将 Cookie 信息也发送给服务端服务端会从 Cookie 中获取 SessionID再根据 SessionID 查找对应的 Session 信息如果没有找到说明用户没有登录或者登录失效如果找到 Session 证明用户已经登录可执行后面操作。
根据以上流程可知SessionID 是连接 Cookie 和 Session 的一道桥梁大部分系统也是根据此原理来验证用户登录状态。
32. Cookie 和 Session 的区别
作用范围不同Cookie 保存在客户端浏览器Session 保存在服务器端。存取方式的不同Cookie 只能保存 ASCIISession 可以存任意数据类型一般情况下我们可以在 Session 中保持一些常用变量信息比如说 UserId 等。有效期不同Cookie 可设置为长时间保持比如我们经常使用的默认登录功能Session 一般失效时间较短客户端关闭或者 Session 超时都会失效。隐私策略不同Cookie 存储在客户端比较容易遭到不法获取早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取Session 存储在服务端安全性相对 Cookie 要好一些。存储大小不同 单个 Cookie 保存的数据不能超过 4KSession 可存储数据远高于 Cookie。
33. 什么是 Http 协议无状态协议?怎么解决?
无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息也就是说当客户端一次 HTTP 请求完成以后客户端再发送一次 HTTP 请求HTTP 并不知道当前客户端是一个”老用户“。
可以使用 Cookie 来解决无状态的问题Cookie 就相当于一个通行证第一次访问的时候给客户端发送一个 Cookie当客户端再次来的时候拿着 Cookie(通行证)那么服务器就知道这个是”老用户“。
34. URI 和 URL 的区别
URI是 uniform resource identifier统一资源标识符用来唯一的标识一个资源。Web 上可用的每种资源如 HTML 文档、图像、视频片段、程序等都是一个来 URI 来定位的。
URI 一般由三部组成
① 访问资源的命名机制② 存放资源的主机名③ 资源自身的名称由路径表示着重强调于资源。
URL 是 uniform resource locator统一资源定位器它是一种具体的 URI即 URL 可以用来标识一个资源而且还指明了如何 locate 这个资源。URL 是 Internet 上用来描述信息资源的字符串主要用在各种 WWW 客户程序和服务器程序上特别是著名的 Mosaic。
采用 URL 可以用一种统一的格式来描述各种信息资源包括文件、服务器的地址和目录等。URL 一般由三部组成
① 协议(或称为服务方式)② 存有该资源的主机 IP 地址(有时也包括端口号)③ 主机资源的具体地址。如目录和文件名等
URNuniform resource name统一资源命名是通过名字来标识资源比如 mailto:java-netjava.sun.com。
如果把 URI 看成是一种抽象的接口定义那么 URL 和 URN 都是一种 URI 的具体实现。笼统地说每个 URL 都是 URI但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类即统一资源名称(URN)它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。
在 Java 的 URI 中一个 URI 实例可以代表绝对的也可以是相对的只要它符合 URI 的语法规则。而 URL 类则不仅符合语义还包含了定位该资源的信息因此它不能是相对的。在 Java 类库中URI 类不包含任何访问资源的方法它唯一的作用就是解析。相反的是URL 类可以打开一个到达资源的流。
35. TCP 粘包/拆包的原因及解决方法
TCP 是以流的方式来处理数据一个完整的包可能会被 TCP 拆分成多个包进行发送也可能把小的封装成一个大的数据包发送。
TCP 粘包/分包的原因 应用程序写入的字节大小大于套接字发送缓冲区的大小会发生拆包现象 而应用程序写入数据小于套接字缓冲区大小网卡将应用多次写入的数据发送到网络上这将会发生粘包现象 进行 MSS 大小的 TCP 分段当 TCP 报文长度 - TCP 头部长度 MSS 的时候将发生拆包 以太网帧的 payload净荷大于 MTU1500 字节进行 ip 分片。
解决方法
① 消息定长即每次发送固定长度字节。 这种方案简单但是缺点是会浪费空间。 比如规定每10个字节表示一个消息但是客户端发送的消息只包含1个字节那么剩余9个字节就需要补空或者补0浪费了。可以使用 FixedLengthFrameDecoder 类。② 包尾使用特殊分隔符比如使用回车符\n作为分隔符再例如 HTTP 报文头中就使用了回车符、换行符作为 HTTP 协议的边界。可以使用行分隔符类 LineBasedFrameDecoder 或自定义分隔符类 DelimiterBasedFrameDecoder 。③ 固定长度字段存储内容的长度信息即将消息分为消息头和消息体在消息头部附加一个固定长度的字段来存储本次消息内容的长度例如在每个消息的头部使用固定4个字节的大小来表示消息内容的长度在接收方解析时也是先读取固定长度的字段获取长度然后根据长度读取数据内容精确定位数据内容不需要转义。缺点数据内容长度有限制需要提前知道最长消息的字节数。可以使用 LengthFieldBasedFrameDecoder 类。
36. 请概要介绍下序列化
序列化编码是将对象序列化为二进制形式字节数组主要用于网络传输、数据持久化等而反序列化解码则是将从网络、磁盘等读取的字节数组还原成原始对象主要用于网络传输对象的解码以便完成远程调用。
影响序列化性能的关键因素序列化后的码流大小网络带宽的占用、序列化的性能CPU 资源占用是否支持跨语言异构系统的对接和开发语言切换。 Java 默认提供的序列化无法跨语言、序列化后的码流太大、序列化的性能差 XML优点人机可读性好可指定元素或特性的名称。 缺点序列化数据只包含数据本身以及类的结构不包括类型标识和程序集信息只能序列化公共属性和字段不能序列化方法文件庞大文件格式复杂传输占带宽。 适用场景当做配置文件存储数据实时数据转换。 JSON是一种轻量级的数据交换格式 优点兼容性高、数据格式比较简单易于读写、序列化后数据较小可扩展性好兼容性好、与 XML 相比其协议比较简单解析速度比较快。 缺点数据的描述性比 XML 差、不适合性能要求为 ms 级别的情况、额外空间开销比较大。 适用场景可替代XML 跨防火墙访问、可调式性要求高、基于 Web browser 的 Ajax 请求、传输数据量相对小实时性要求相对低例如秒级别的服务。 Fastjson采用一种“假定有序快速匹配”的算法。 优点接口简单易用、目前 java 语言中最快的 json 库。 缺点过于注重快而偏离了“标准”及功能性、代码质量不高文档不全、安全漏洞较多。 适用场景协议交互、Web 输出、Android 客户端 Thrift不仅是序列化协议还是一个 RPC 框架。 优点序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。 缺点使用者较少、跨防火墙访问时不安全、不具有可读性调试代码时相对困难、不能与其他传输层协议共同使用例如 HTTP、无法支持向持久层直接读写数据即不适合做数据持久化序列化协议。 适用场景分布式系统的 RPC 解决方案 Protobuf将数据结构以 .proto 文件进行描述通过代码生成工具可以生成对应数据结构的 POJO 对象和 Protobuf 相关的方法和属性。 优点序列化后码流小性能高、结构化数据存储格式XML JSON 等、通过标识字段的顺序可 以实现协议的前向兼容、结构化的文档更容易管理和维护。 缺点需要依赖于工具生成代码、支持的语言相对较少官方只支持 Java 、C 、python。 适用场景对性能要求高的 RPC 调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化
37. select、poll、epoll 的区别
selectpollepoll 都是 操作系统实现 IO 多路复用的机制。 我们知道I/O 多路复用就通过一种机制可以监视多个描述符一旦某个描述符就绪一般是读就绪或者写就绪能够通知程序进行相应的读写操作。那么这三种机制有什么区别呢
1、支持一个进程所能打开的最大连接数
IO 多路复用名称能打开的最大连接数select单个进程所能打开的最大连接数有 FD_SETSIZE 宏定义其大小是 1024 当然我们可以对进行修改然后重新编译内核但是性能可能会受到影响。pollpoll 本质上和 select 没有区别但是它没有最大连接数的限制原因是它是基于链表来存储的epoll连接数基本上只受限于机器的内存大小
2、FD 剧增后带来的 IO 效率问题
IO 多路复用名称IO 效率select因为每次调用时都会对连接进行线性遍历所以随着 FD 的增加会造成遍历速度慢的“线性下降性能问题”。poll同上epoll因为 epoll 内核中实现是根据每个 fd 上的 callback 函数来实现的只有活跃的 socket 才会主动调用 callback所以在活跃socket 较少的情况下使用 epoll 没有前面两者的线性下降的性能问题但是所有 socket 都很活跃的情况下可能会有性能问题。
3、 消息传递方式
IO 多路复用名称消息传递方式select内核需要将消息传递到用户空间都需要内核拷贝动作poll同上epollepoll 通过内核和用户空间共享一块内存来实现
总结
综上在选择 selectpollepoll 时要根据具体的使用场合以及这三种方式的自身特点。
表面上看 epoll 的性能最好但是在连接数少并且连接都十分活跃的情况下select 和 poll 的性能可能比 epoll 好毕竟 epoll 的通知机制需要很多函数回调。select 低效是因为每次它都需要轮询。但低效也是相对的视情况而定也可通过良好的设计改善。
38. 什么是水平触发(LT)和边缘触发(ET)
条件触发Level_triggered又叫水平触发当被监控的文件描述符上有可读写事件发生时epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完如读写缓冲区太小那么下次调用 epoll_wait() 时它还会通知你在上没读写完的文件描述符上继续读写当然如果你一直不去读写它会一直通知你如果系统中有大量你不需要读写的就绪文件描述符而它们每次都会返回这样会大大降低处理程序检索自己关心的就绪文件描述符的效率
边缘触发Edge_triggered当被监控的文件描述符上有可读写事件发生时epoll_wait() 会通知处理程序去读写。如果这次没有把数据全部读写完如读写缓冲区太小那么下次调用 epoll_wait() 时它不会通知你也就是它只会通知你一次直到该文件描述符上出现第二次可读写事件才会通知你这种模式比水平触发效率高系统不会充斥大量你不关心的就绪文件描述符
简单的理解也就是一个会一直不停的通知用户另一个只会通知用户一次。
总结
条件触发只要满足事件的条件比如有数据需要读就一直不断的把这个事件传递给用户边缘触发只有第一次满足条件的时候才触发之后就不会再传递同样的事件了边缘触发的效率比条件触发的效率高epoll 支持边缘触发和条件触发默认是条件触发select 和 poll 都是条件触发
39. 什么是直接内存
在所有的网络通信和应用程序中每个 TCP 的 Socket 的内核中都有一个发送缓冲区(SO_SNDBUF)和一个接收缓冲区(SO_RECVBUF)可以使用相关套接字选项来更改该缓冲区大小。 当某个应用进程调用 write 时内核从该应用进程的缓冲区中复制所有数据到所写套接字的发送缓冲区。如果该套接字的发送缓冲区容不下该应用进程的所有数据或是应用进程的缓冲区大于套接字的发送缓冲区或是套接字的发送缓冲区中已有其他数据假设该套接字是阻塞的则该应用进程将被投入睡眠。
内核将不从 write 系统调用返回直到应用进程缓冲区中的所有数据都复制到套接字发送缓冲区。因此从写一个 TCP 套接字的 write 调用成功返回仅仅表示我们可以重新使用原来的应用进程缓冲区并不表明对方的 TCP 或应用进程已接收到数据。 Java 程序自然也要遵守上述的规则。但在 Java 中存在着堆、垃圾回收等特性所以在实际的 IO 中在 JVM 内部的存在着这样一种机制
在 IO 读写上如果是使用堆内存JDK 会先创建一个 DirectBuffer再去执行真正的写操作。这是因为当我们把一个地址通过 JNI 传递给底层的 C 库的时候有一个基本的要求就是这个地址上的内容不能失效。然而在 GC 管理下的对象是会在 Java 堆中移动的。也就是说有可能我把一个地址传给底层的 write但是这段内存却因为 GC 整理内存而失效了。所以必须要把待发送的数据放到一个 GC 管不着的地方。这就是调用 native 方法之前数据—定要在堆外内存的原因。
可见DirectBuffer 并没有节省什么内存拷贝只是因为 HeapBuffer 必须多做一次拷贝使用 DirectBuffer 就会少一次内存拷贝。相比没有使用堆内存的 Java 程序使用直接内存的 Java 程序当然更快一点。
从垃圾回收的角度而言直接内存不受 GC(新生代的 Minor GC) 影响只有当执行老年代的 Full GC 时候才会顺便回收直接内存整理内存的压力也比数据放到 HeapBuffer 要小。
堆外内存的优点和缺点
堆外内存相比于堆内内存有几个优势
减少了垃圾回收的工作因为垃圾回收会暂停其他的工作可能使用多线程或者时间片的方式根本感觉不到加快了复制的速度。因为堆内在 flush 到远程时会先复制到直接内存非堆内存然后在发送而堆外内存相当于省略掉了这个工作。
而福之祸所依自然也有不好的一面 3. 堆外内存难以控制如果内存泄漏那么很难排查 4. 堆外内存相对来说不适合存储很复杂的对象。一般简单的对象或者扁平化的比较适合。
40. 什么是零拷贝?
零拷贝Zero-copy 技术是指计算机执行操作时CPU 不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省 CPU 周期和内存带宽。
零拷贝技术可以减少数据拷贝和共享总线操作的次数消除传输数据在存储器之间不必要的中间拷贝次数从而有效地提高数据传输效率。零拷贝技术减少了用户进程地址空间和内核地址空间之间因为CPU上下文切换而带来的开销
可见零拷贝并不是说不需要拷贝只是说减少冗余 [不必要] 的拷贝。
Linux 的 I/O 机制与 DMA
在早期计算机中用户进程需要读取磁盘数据需要 CPU 中断和 CPU 参与因此效率比较低发起 IO 请求每次的 IO 中断都带来 CPU 的上下文切换。因此出现了——DMA。
DMADirect Memory Access直接内存存取 是所有现代电脑的重要特色它允许不同速度的硬件装置来沟通而不需要依赖于 CPU 的大量中断负载。
DMA 控制器接管了数据读写请求减少 CPU 的负担。这样一来CPU 能高效工作了。现代硬盘基本都支持 DMA。
因此实际 IO 读取涉及两个过程
DMA 等待数据准备好把磁盘数据读取到操作系统内核缓冲区用户进程将内核缓冲区的数据 copy 到用户空间。
这两个过程都是阻塞的。
传统数据传送机制
比如读取文件再用 socket 发送出去实际经过四次 copy。伪码实现如下
buffer File.read()
Socket.send(buffer)第一次将磁盘文件读取到操作系统内核缓冲区第二次将内核缓冲区的数据copy 到应用程序的 buffer第三步将 application 应用程序 buffer 中的数据copy 到 socket 网络发送缓冲区(属于操作系统内核的缓冲区)第四次将 socket buffer 的数据copy 到网卡由网卡进行网络传输。 分析上述的过程虽然引入 DMA 来接管 CPU 的中断请求但四次 copy 是存在“不必要的拷贝”的。实际上并不需要第二个和第三个数据副本。应用程序除了缓存数据并将其传输回套接字缓冲区之外什么都不做。相反数据可以直接从读缓冲区传输到套接字缓冲区。
显然第二次和第三次数据 copy 其实在这种场景下没有什么帮助反而带来开销这也正是零拷贝出现的背景和意义。
同时read 和 send 都属于系统调用每次调用都牵涉到两次上下文切换 总结下传统的数据传送所消耗的成本4 次拷贝4 次上下文切换。4 次拷贝中两次是 DMA copy两次是 CPU copy。
Linux 支持的常见零拷贝
目的减少 IO 流程中不必要的拷贝当然零拷贝需要 OS 支持也就是需要kernel 暴露 api。 mmap 内存映射 硬盘上文件的位置和应用程序缓冲区(application buffers)进行映射建立一 种一一对应关系由于 mmap() 将文件直接映射到用户空间所以实际文件读取时根据这个映射关系直接将文件从硬盘拷贝到用户空间只进行了一次数据拷贝不再有文件内容从硬盘拷贝到内核空间的一个缓冲区。 mmap 内存映射将会经历3 次拷贝: 1 次 cpu copy2 次 DMA copy以及 4 次上下文切换 sendfile linux 2.1 支持的 sendfile当调用 sendfile() 时DMA 将磁盘数据复制到 kernel buffer然后将内核中的 kernel buffer 直接拷贝到 socket buffer。在硬件支持的情况下甚至数据都并不需要被真正复制到 socket 关联的缓冲区内。取而代之的是只有记录数据位置和长度的描述符被加入到 socket 缓冲区中DMA 模块将数据直接从内核缓冲区传递给协议引擎从而消除了遗留的最后一次复制。 一旦数据全都拷贝到 socket buffersendfile() 系统调用将会 return代表数据转化的完成。socket buffer 里的数据就能在网络传输了。 sendfile 会经历3 次拷贝1 次 CPU copy 2 次 DMA copy硬件支持的情况下则是 2 次拷贝0 次 CPU copy 2 次 DMA copy。 以及 2 次上下文切换 splice Linux 从 2.6.17 支持 splice数据从磁盘读取到 OS 内核缓冲区后在内核缓冲区直接可将其转成内核空间其他数据 buffer而不需要拷贝到用户空间。 如下图所示从磁盘读取到内核 buffer 后在内核空间直接与 socket buffer 建立 pipe 管道。 和 sendfile() 不同的是splice() 不需要硬件支持。 注意 splice 和 sendfile 的不同sendfile 是将磁盘数据加载到 kernel buffer 后需要一次 CPU copy拷贝到 socket buffer。而 splice 是更进一步连这个 CPU copy 也不需要了直接将两个内核空间的 buffer 进行 pipe。 splice 会经历 2 次拷贝: 0 次 cpu copy 2 次 DMA copy以及 2 次上下文切换
总结 Linux 中零拷贝
最早的零拷贝定义来源于 Linux 2.4 内核新增 sendfile 系统调用提供了零拷贝。磁盘数据通过 DMA 拷贝到内核态 Buffer 后直接通过 DMA 拷贝到 NIO Buffer(socket buffer)无需 CPU 拷贝。 这也是零拷贝这一说法的来源。这是真正操作系统 意义上的零拷贝也就是狭义零拷贝。
但是我们知道由 OS 内核提供的 操作系统意义上的零拷贝发展到目前也并没有很多种也就是这样的零拷贝并不是很多随着发展零拷贝的概念得到了延伸就是目前的减少不必要的数据拷贝都算作零拷贝的范畴。
41. Linux 中有哪些 IO 模型?
Linux 下的五种网络 IO 模型
① 阻塞式IOblocking IO② 非阻塞式IOnoblocking IO③ IO复用式(select、poll和epoll)IO multiplexing④ 信号驱动式IO(signal-driven IO⑤ 异步IOasynchronous IO
除了第 ⑤ 种其他四种都属于同步 IO 。
5 个 I/O 模型的比较
不同 I/O 模型的区别其实主要在等待数据和数据复制这两个时间段不同。
42. epoll 高效的原理 当某一进程调用 epoll_create() 方法时Linux 内核会创建一个 eventpoll 结构体在内核 cache 里建了个红黑树用于存储以后 epoll_ctl() 传来的 socket 外还会再建立一个 rdllist 双向链表用于存储准备就绪的事件当 epoll_wait() 调用时仅仅观察这个 rdllist 双向链表里有没有数据即可。有数据就返回没有数据就 sleep等到 timeout 时间到后即使链表没数据也返回。 同时所有添加到 epoll 中的事件都会与设备如网卡驱动程序建立回调关系也就是说相应事件的发生时会调用这里的回调方法。这个回调方法在内核中叫做 ep_poll_callback它会把这样的事件放到上面的 rdllist 双向链表中。 当调用 epoll_wait() 检查是否有发生事件的连接时只是检查 eventpoll 对象中的 rdllist 双向链表是否有 epitem 元素而已如果 rdllist 链表不为空则这里的事件复制到用户态内存使用共享内存提高效率中同时将事件数量返回给用户。因此 epoll_wait() 效率非常高可以轻易地处理百万级别的并发连接。
43. 如果要你来设计一个QQ在网络协议上你会考虑如何设计
登陆采用 TCP 协议和 HTTP 协议你和好友之间发送消息主要采用 UDP 协议内网传文件采用了 P2P 技术。
总来的说
登陆过程客户端 client 采用 TCP 协议向服务器 server 发送信息HTTP 协议下载信息。登陆之后会有一个 TCP 连接来保持在线状态。和好友发消息客户端 client 采用 UDP 协议但是需要通过服务器转发。腾讯为了确保传输消息的可靠采用上层协议来保证可靠传输。如果消息发送失败客户端会提示消息发送失败并可重新发送。如果是在内网里面的两个客户端传文件QQ 采用的是 P2P 技术不需要服务器中转。
