计算机网络面试题总结

（1） 建立TCP服务器的各个系统调用
（2） 继上一题，说明socket网络编程有哪些系统调用？其中close是一次就能直接关闭的吗，半关闭状态是怎么产生的？
（3） 对路由协议的了解与介绍。内部网关协议IGP包括RIP，OSPF，和外部网关协议EGP和BGP.
（4） 路由协议所使用的算法。

（5） TCP和UDP的区别

• TCP是有连接的协议，UDP是无连接的协议
• TCP传输的是字节流，把数据看成一连串无结构的字节流；UDP传输的是报文段
• TCP是可靠的传输，传输的数据保证无差错、不丢失、不重复、按序到达；UDP是不可靠的传输，尽最大努力交付
• TCP传输效率低速度慢，UDP传输效率高，速度快
• TCP有流量控制机制滑动窗口和拥塞控制机制（慢开始、拥塞避免、快重传、快恢复），UDP没有流量控制机制和拥塞控制机制
• TCP只能是点到点的全双工通信，UDP可以是一对多、多对一、一对一、多对多

（6） TCP和UDP相关的协议与端口号

参考链接：https://blog.csdn.net/qq_22080999/article/details/81105051

TCP相关的协议：

• Telnet(23)
• SMTP(25)
• FTP(20、21)
• HTTP(80)
• HTTPS(443)
• DNS(53):仅在区之间进行通信的时候采用TCP
• POP3
• SSH
• NTP
• IMAP4

UDP相关协议：

• SNTP
• TFTP
• DNS(53)
• BooTPS/DHCP

（7） TCP（UDP，IP）等首部的认识（http请求报文构成）

（8） 在浏览器中输入URL后执行的全部过程（如www.baidu.com）

参考链接：https://www.zhihu.com/question/23042131
参考链接：https://www.cnblogs.com/wpshan/p/6282061.html

url包括哪几部分：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
协议，域名，端口号（域名和端口之间冒号分隔，可省略），虚拟目录（域名后第一个“/”开始到第一个“/”为止），文件名（最后一个“/”开始到“？”为止，可省略），参数（“？”和“#”之间的内容，以“？”作为分隔符），锚（“#”开始到最后）

• 1.用户输入网址，浏览器发起DNS查询请求，将域名解析成IP地址
  DNS域名解析过程：

  • 系统先检查自己的本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析；
  • 如果hosts里没有这个域名映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有直接返回，完成域名解析；
  • 如果本地hosts和本地DNS解析器缓存都没有相应的网址映射关系，首先会找TPC/IP参数中设置的首选DNS服务器（本地服务器），此服务器收到查询时，如果要查询的域名在本地的配置资源中，则将解析结果返回给客户机，完成域名解析，此解析具有权威性；
  • 如果要查询的域名，不由本地DNS服务器区域解析，但该 服务器已缓存（本地服务器缓存） 了此网址的映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性；
  • 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是由谁来授权管理，并会返回一个负责该顶级域名服务器的IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器，这台服务器收到请求后，如果自己无法解析，他就会找一个管理.com域的下一级DNS服务器baidu.com给本地DNS服务器。本地DNS服务器收到这个地址后，就会找baidu.com域服务器，重复上面的动作，直到找到www.baidu.com主机。
  • 如果是转发模式，此DNS服务器就会把请求转致上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或者找根DNS或者转请求至上上级，以此循环。不管是本地DNS服务器用转发还是根提示，最后都把结果返回给DNS服务器，由此DNS服务器再返回给客户机。

  从客户端到本地DNS服务器属于递归查询，DNS服务器之间就是迭代查询。
  总结： 本地hosts文件–>本地DNS解析器缓存–>本地DNS服务器–>本地DNS服务器缓存–>（未用转发模式）13台根DNS查询；
  本地hosts文件–>本地DNS解析器缓存–>本地DNS服务器–>本地DNS服务器缓存–>（转发模式）上一级DNS服务器；

• 2.建立TCP连接
  浏览器获得IP地址后，向服务器发起tcp连接请求，通过TCP三次握手连接好后，浏览器便可将http请求发送给服务器

• 3.发送http请求报文
  http请求是基于TCP协议之上的应用层协议

• 4.发送响应数据给客户端

• 5.浏览器解析响应报文

总结：
在这个过程中用到的协议：
应用层：dns, http
传输层：tcp,udp
网络层：ip,arp

（9） 网页解析的过程与实现方法
浏览器收到服务器的响应资源后，会对资源进行解析。

• 查看响应报文的头部，根据不同的状态码做不同的事情（3xx需要重定向），如果响应资源进行了压缩还需要进行解压，然后对响应资源缓存
• 根据响应资源的类型进行解析

（10） 网络层（IP数据报）分片的原因与具体实现

参考链接：https://my.oschina.net/xinxingegeya/blog/483138

分片的原因：数据链路层的MTU（最大传输单元）限制了所传输的IP数据报的大小，MTU指一次传送数据的最大长度，不包括数据链路层数据帧的头部。当发送的IP数据报（最大是65535字节）的大小超过了MTU时，IP层就要对数据进行分片。

分片的数据报会以不同的路径传输到接收的主机，接收的主机通过重组，将其还原为一个完整的数据报，再交给上层协议

实现方法：通过IP数据报中的标识符（16位），标志位（3位），偏移量（13位）实现IP数据报的分片和重组

• 标识符：同一个数据报的若干分片具有一样的值
• 标志位：R（保留位），DF（不允许分段），MF(1：表示当前数据报还有更多分片，0：表示当前分片的最后一个分片)
• 偏移量：表示当前数据报分片数据起始位置在完整数据报中的偏移，（一个单位代表8个字节）

操作系统内核协议栈只需要申请一块和原始数据报相同大小的内存空间，然后将这些数据报分片按照其偏移拷贝到指定位置就能恢复出原来的数据报。

如果只单单依赖标识符（16位）进行分片的话，只能标识65536个数据报，当超过65536时，就会出现重复的数据报分片，实际上协议栈用（标识符、源地址、目标地址、协议）来标识唯一的IP数据报分片

分片带来的问题：

• 性能消耗：分片和重组会消耗发送方和接收方一定的CPU资源，如果存在大量的分片的话，可能造成严重的资源消耗；分片接收方内存资源的消耗较多，因为接收方要为每个分片报文分配内存空间，以便于最后一个分片报文到达后完成重组
• 分片丢包导致超时重传：
  IP层没有超时重传机制，如果某个分片报文在网络传输过程中丢失，那么接收方将无法完成重组，如果应用进程要求重传的话，发送方必须重传所有分片报文，而不是仅重传被丢弃的那个分片报文，这种效率低下的重传行为会给端系统和网络资源带来额外消耗。
• 分片攻击：
  黑客构造的分片报文，不向接收方发送最后一个分片，导致接收方无法完成分片报文的重组，从而不能释放分片报文所占用的空间，接收方会启动一个分片重组定时器，当定时器时间到了以后，会向发送方大宋ICMP重组超时差错报文，只要这种攻击的分片报文发送的足够多足够快，会迅速招满接收方的内存，使得接收方无内存处理正常的业务，从而达到DOS攻击的效果
• 安全隐患：由于只有第一个分片具有四层信息而其他分片没有，会给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。如果防火墙、路由器等中间设备不对分片报文进行安全策略的匹配检测，直接放行IP分片报文，有可能会给接收方带来安全隐患；如果防火墙、路由器对分片报文进行重组后再匹配其安全策略，那么会给这些中间设备带来极大的资源消耗。

分片的情况：

• 对于TCP协议，应用层（对上）不用考虑分片，因为传输层在TCP三次握手的过程中，双方会通告MSS（最大报文段长），每次发送的数据不超过MSS，MSS=MTU-IP首部（20）-TCP首部（20），从而保证了IP数据报不会超过MTU，所以就不用进行分片；（对下）如果发送过长的TCP报文，TCP报文会进行分段。
• 对于UDP包，需要在应用层（对上）限制每个包的大小MTU-IP首部（20）-UDP头部（8）字节；UDP数据报不会自己进行分段，当长度超过MTU时，会在网络层（对下）进行IP分片，分片后的数据，传输层的首部只会出现在第一个分片报文中

（11） TCP的三次握手与四次挥手的详细介绍（TCP连接建立与断开是热门问题）

参考：https://www.cnblogs.com/tuyang1129/p/12435772.html
SYN：表示建立连接的报文
ACK：确认报文
seq：序号
ack：确认序号，也就是期待接收到的下一个序号

三次握手过程：

• 第一次：客户端向服务端发送SYN报文（建立连接报文），SYN=1,seq=x
• 第二次：服务端向客户端发送SYN+ACK报文，SYN=1,ACK=1,seq=y,ack=x+1
• 第三次：客户端向服务端发送ACK报文，这次可携带数据，SYN=0,ACK=1,seq=x+1,ack=y+1

问题一：为什么需要三次握手？两次握手不可以吗？
参考链接：https://draveness.me/whys-the-design-tcp-three-way-handshake/

• 初始序列号： 首先说明一点：双方在建立连接的过程，其实做了两件事，一方面是建立连接，另一方面是互相通知对方的初始序号（作用：去除重复的数据包；重新发送丢失的数据包；根据数据包的序列号进行排序），也就是同步的过程，第三次握手是告诉服务端，服务端的初始序号值已经收到，可以进行正常通信。如果是两次握手，服务器无法保证客户端已经收到自己的ACKSYN报文段，第二次握手的报文，客户端没有收到，客户端不知道服务器的初始序列号，将无法处理之后到达客户端的数据。
• 为了阻止历史的重复连接初始化造成的混乱： 如果是两次握手，第一次握手发送了建立连接的报文，由于网络拥塞等原因，这个报文服务端迟迟没有收到，于是客户端再一次发送建立连接的报文，服务端收到了，建立了连接，传输完数据很快就断开了，此时，如果一开始发送的建立连接的报文服务端又收到了，以为客户端又想建立一条新的连接，分配了一些建立连接的资源。由于没有第三次握手，服务器不知道是之前的报文，于是建立了一个新的连接并维持，直至太久没有接收到数据而释放，造成了资源的浪费。在三次握手的情况下，如果当前是历史连接，seq过期或者超时，发送方就会直接发送RST报文，终止这一次连接；如果当前不是历史连接，发送方就会发送ACK消息，通信双方就会成功建立连接

为什么不能是四次？
使用更多的通信次数当然可以建立连接，在三次握手就能够建立连接的前提下，更多的通信次数没有意义。第二次可以将ACK和SYN同时发送，减少了通信次数

问题二：第三次握手失败了会怎么办？

参考：https://www.jianshu.com/p/406dc9785a78
参考：https://blog.csdn.net/gochenguowei/article/details/79649997?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param
此时服务端迟迟收不到确认，服务器会重传SYN+ACK报文（第二次握手的报文），重发指定次数后，超过一定时间后，服务端会发送RST报文段，表示连接信息全部被初始化，原有的TCP通信不能继续，进入closed状态，以防止洪范攻击（服务端返回ACK后，客户端故意不确认，使得服务器不断重发ACK，占用服务端大量的资源，使得服务端资源耗尽，导致死机，这就是洪泛攻击）.
因为第二次握手成功后，客户端就处于established状态，成功建立连接的状态，他就会向服务端发数据，服务端会反馈给客户端RST报文，就能够知道三次握手失败了。

问题三：客户端与服务端建立TCP连接，当服务器变为SYN-RCVD后，此时一个旧的SYN报文到达，服务器会如何处理？
服务器并不会识别出该报文是一个旧的SYN报文，而是正常向客户端发送SYN+ACK报文，当客户端收到该报文后，发现ack不对，就会发送RST报文，将服务端重置为LISTEN状态

问题四：双方如果同时发送建立连接的SYN报文会出现什么状况？
只有一方的连接会建立成功

四次挥手：

• 客户端向服务端发送FIN报文
• 服务端向客户端发送ACK报文
• 服务端向客户端发送FIN报文
• 客户端向服务端发送ACK报文

问题一：四次挥手过程，在第四次挥手后问什么还会等待2MSL？

• 一方面是保证第四次挥手，客户端向服务端发送的ACK报文成功到达服务端，如果客户端立即释放资源，那么当第四次挥手失败，客户端将无法处理服务端超时重传的FIN报文，所以客户端要等待2MSL.
• 另一方面，等待该连接在网络中遗留的报文死掉，例如那些超时未到达的数据报

问题二：为什么需要四次挥手？
TCP是全双工的通信，断开连接的时候，如果客户端是主动请求方，首先断开的是客户端到服务端方向的连接，意味着客户端数据已经传送完毕，关闭连接即可，但是这时候，服务端的数据可能还没有传送完毕，等到服务端到客户端的数据也发送完毕，再断开服务端到客户端的连接。
如果是两次挥手，一方关闭连接后，就意味着整个连接关闭，可能会导致另一方的数据还没有传送完，连接就断开了。

问题三：第四次挥手失败会怎么办？
参考链接：https://xiaozhuanlan.com/topic/9021345678
第四次挥手失败，就意味着最后一个ACK报文丢失，服务端会超时重传FIN报文，客户端在收到一个FIN报文后会进入TIME_WAIT状态，并开启定时器，等待2MSL，等待的时间可以使客户端在ACK报文丢失的情况下等待下一个FIN报文的到来。如果在TIME_WAIT有一个新的ACK报文到达，看就会重新设置定时器。
如果重传的FIN到达客户端时，客户端已经进入CLOSE状态，客户端就永远收不到这个报文，此时，服务端会不断地进行探查，经过几次探查后，如果都没有受到回应，则认为客户端已经关闭了，服务器也将关闭，终止连接。

（12） TCP握手以及每一次握手客户端和服务器端处于哪个状态（11种状态）

三次握手过程：

• 客户端发送SYN报文，由CLOSED状态变为SYN-SENT状态
• 服务端收到SYN报文，并发送SYN+ACK报文，由listen状态变为SYN-RECV状态
• 客户端收到SYN+ACK报文，并发送ACK报文，由SYN-SENT状态变为ESTABLISHED状态；服务端收到ACK报文，由AYN-RECV状态变为ESTABLISHED状态
  

四次挥手过程：

• 客户端发送FIN报文，由ESTABLISHED状态变为FIN-WAIT1状态
• 服务端收到FIN报文，发送ACK报文，由ESTABLISHED状态变为CLOSED-WAIT状态
• 客户端收到ACK报文，由FIN-WAIT1状态变为FIN-WAIT2状态
• 服务端发送FIN报文，由CLOST-WAIT状态变为LAST-ACK状态
• 客户端收到FIN报文，发送ACK报文，由FIN-WAIT2状态变为TIME-WAIT状态
• 服务端收到ACK报文，由LAST-ACK状态变为CLOAED状态
  

（13） 为什么使用三次握手，两次握手可不可以？

参考链接：https://zhuanlan.zhihu.com/p/103000747

• 首先说明一点：双方在建立连接的过程，其实做了两件事，一方面是建立连接，另一方面是互相通知对方的初始序号，也就是同步的过程，第三次握手是告诉服务端，服务端的初始序号值已经收到，可以进行正常通信。如果是两次握手，服务器无法保证客户端已经收到自己的ACKSYN报文段，第二次握手的报文，客户端没有收到，客户端不知道服务器的出事序列号，将无法处理之后到达客户端的数据。
• 如果是两次握手，第一次握手发送了建立连接的报文，由于网络拥塞等原因，这个报文服务端迟迟没有收到，于是客户端再一次发送建立连接的报文，服务端收到了，建立了连接，传输完数据很快就断开了，此时，如果一开始发送的建立连接的报文服务端又收到了，以为客户端又想建立一条新的连接，分配了一些建立连接的资源。由于没有第三次握手，服务器不知道是之前的报文，于是建立了一个新的连接并维持，直至太久没有接收到数据而释放，造成了资源的浪费。

（14） TIME_WAIT的意义（为什么要等于2MSL）

• 一方面是保证第四次挥手，客户端向服务端发送的ACK报文成功到达服务端，如果客户端立即释放资源，那么当第四次挥手失败，客户端将无法处理服务端超时重传的FIN报文，所以客户端要等待2MSL.
• 另一方面，等待该连接在网络中遗留的报文死掉，例如那些超时未到达的数据报

（15） 超时重传机制（不太高频）

（16） TCP怎么保证可靠性（面向字节流，超时重传，应答机制，滑动窗口，拥塞控制，校验等）？

参考链接：https://blog.csdn.net/liuchenxia8/article/details/80428157

TCP保证可靠性传输的机制：校验和、序列号（seq）、确认应答(ack)、超时重传、连接管理、流量控制、拥塞控制

• 校验和：通过校验和检测数据是否有差错和异常
• 序列号和确认应答：每发送一个数据包，接收端就会发送确认的序列号，这个确认的序列号是期待下一次收到的包的序列号
• 超时重传：发送方在一定时间内没有收到确认，会对待确认的包进行重传
• 建立连接：tcp三次握手、tcp四次挥手
• 流量控制：
  通信双方会根据TCP协议报头信息中，16位接收窗口的大小，来控制双方发送的速度，当接收方收到报文，会发送一个ACK报文，在该报文的头部会告诉自己数据缓冲区的大小。发送方会根据ACK报文里的窗口大小的改变而改变自己的发送速度，如果接收到的窗口值为0，则会停止发送数据。
  这样处理可以，避免由于对方的缓冲区满了而造成的丢包，从而引发一系列的连锁反应，例如：超时重传等等。
• 拥塞控制(慢启动、拥塞避免、快重传、快恢复)
  拥塞控制是指双方在进行通信时，采用慢启动的机制，先发送少量的数据，探测网络的情况，这样可以避免，开始网络十分拥堵时，就发送大量的数据，加巨了网络的拥堵程度；
  慢启动：开始时，发送的慢，一旦发送起来数据增长是非常快的，数据呈指数增长；当达到设定的阈值后，线性增长，一旦造成了网络拥塞，阈值变为拥塞窗口的一一半，同时拥塞窗口重置为1

（17）TCP长连接和短连接

参考链接：https://www.cnblogs.com/0201zcr/p/4694945.html

• 短连接：通信的双方建立连接后，进行一次数据的传输，就会关闭连接
• 长连接：通信的双方建立连接后，进行一次数据传输后，不会关闭连接，后续的数据传输依然使用该连接

二者的优缺点：

• 短连接不需要占用系统太多的资源，从而服务端可以处理更多的客户端的连接；但是如果客户端请求频繁，需要不断的进行建立连接和断开连接的操作，会浪费时间和带宽。
• 长连接传输速度快，不需要频繁的建立连接和断开连接的操作，但是会占用系统较多的资源。如果建立好一个长连接后，在给定的时间内，通信双方没有任何动作，服务器就会像客户发送探测报文段。

适用场景：

• 长连接用于操作频繁，连接数不多的情况，例如：数据库连接
• 短连接适用于web网站的http服务，因为会有大量的客户端和服务端建立连接，使用短连接更节省资源。

（17） 流量控制的介绍，采用滑动窗口会有什么问题（死锁可能，糊涂窗口综合征）？

流量控制的过程中，如果接收方的接收窗口变为0，告知发送方，发送方窗口关闭。当接收方处理完数据后，会向发送方通告一个窗口非0的ACK报文，如果这个报文丢失了，不采取任何措施，双方就会处于等待状态，就造成了死锁。

如何解决这种潜在的死锁现象？
TCP为每个连接设有一个持续的定时器，只要TCP连接一方收到对方的0窗口通知，就会启动持续计时器。如果持续计时器超时，就会发送窗口探测报文，而对方在确认这个探测报文时，会给出自己现在的接收窗口的大小。如果接收方窗口仍然为0，那么收到这个报文的一方就会重新启动持续计时器；如果接收窗口不是0，那么死锁的局面就打破了。

糊涂窗口综合症：
如果接收方太忙了，来不及取走接收窗口里的数据，那么就会导致发送方发送的窗口越来越小，到最后如果接收方腾出几个字节并告诉发送方现在有几个字节，而发送方会义无反顾的发送这几个字节，这就是糊涂窗口综合症。这就需要用很大的开销（TCP报文头部有40个字节）但是只传几个字节的数据。

解决糊涂窗口综合症要解决两个问题：

• 接收方不通告一个小窗口
  当接收方的窗口太小时，不通告实际的值，而是通告窗口为0，阻止发送方发送数据
• 发送方避免发送小数据
  使用Nagle算法，当窗口大小大于MSS或者数据大小大于MSS，收到之前发送数据的ack包，当满足这两个条件时，才可以发送数据。
  （18） tcp滑动窗口协议
  （19） 拥塞控制和流量控制的区别
  （20） TCP拥塞控制，算法名字？（极其重要）
  （21） http协议与TCP联系
  （22） http/1.0和http/1.1的区别

（23） http的请求方法有哪些？get和post的区别。

参考链接：https://www.cnblogs.com/biyeymyhjob/archive/2012/07/28/2612910.html

http有请求报文和响应报文。
请求报文由以下四部分组成：请求行、请求头部、空行、请求数据，请求方式有（GET,POST,HEAD,PUT,DELETE,OPTIONS,CONNECT,TRACE）
响应报文由以下三部分组成：状态行、消息头部、响应正文

get和post的区别：

• 请求的数据：get提交会把请求的数据放在url之后，也就是在请求报文的请求行部分，get提交的数据会在地址栏中显示出来；post会把请求的数据放在请求报文的请求数据部分，post提交数据后，地址栏不会改变
• 传输数据的长度：虽然http协议没有对传输的数据大小进行限制，也没有对url的长度进行限制；但是在实际的开发中get特定浏览器和服务器对url对数据的长度有限制，post理论上数据不受限
• 安全性：post的安全性比get的安全性高，通过get提交数据，用户名和密码将出现在明文url上，比如登录页面有可能被缓存，其他人查看浏览器的历史记录就可以拿到你的用户名和密码了

（24） http的状态码

• 1xx：指示信息
• 2xx：操作成功
• 3xx：还需进一步处理
• 4xx：客户端出现错误
• 5xx：服务端出现错误

常用的状态码：

• 200：客户端请求操作成功
• 400：请求报文有语法错误
• 401：请求报文未经授权
• 403：服务端成功收到报文，但拒绝提供服务
• 404：请求报文的资源不存在，例如：错误的URL
• 500：服务端出现不可预期的错误
• 503：服务端暂时不能提供服务，稍后可以正常

（25）http长连接和短连接

参考链接：https://www.cnblogs.com/0201zcr/p/4694945.html

http长连接和短连接本质上是tcp长连接和短连接。

• 短连接：http/1.0默认使用的是短连接，浏览器和服务器之间每进行一次http请求就会建立一次连接，任务结束就会中断连接。
• 长连接：http/1.1起，默认使用的是长连接（keep-alive），浏览器和服务器之间建立连接后会保持一段时间，一个网页打开完成后，这个连接不会断开，如果浏览器再次访问网页会继续使用这个长连接，连接保持的时间可以在不同的服务器软件中进行设定

（26）http报文头部组成

参考链接：https://blog.csdn.net/ulike_MFY/article/details/79550241

http报文分为：请求报文和响应报文
请求报文：请求行，请求头部，空行，请求数据

• 请求行：请求方法，url，http协议版本

相应报文：响应行，响应头部，空行，响应数据

• 响应行：协议版本、状态码、描述符

（27）cookie和session

参考链接：https://www.cnblogs.com/lyugeyi1030/p/8545813.html

http协议是无状态的，协议对于事务处理没有记忆能力，服务器不知道客户端处于什么状态。也就是说，打开一个服务器上的网页和之前打开这个服务器上的网页之间没有任何的联系。

• session在服务端用于保存每个用户的信息，每个用户都有一个对应的session id，它会保存到用户持续请求的一段时间再加上一段时间
• cookie用于保存用户浏览器（客户端）请求服务器页面的信息，信息保存的时间可以根据需要设置（保存在硬盘中），如果没有设置会保存到关闭浏览器为止（保存在浏览器内存中）

（25） http和https的区别，由http升级为https需要做哪些操作
（26） https的具体实现，怎么确保安全性
（27） http中浏览器一个URL的流程，这个过程中浏览器做了什么，URL包括哪三个部分？

（28）DNS劫持

DNS劫持是指：

• 当客户端向DNS服务器发送查询请求时，在未到达DNS服务器时，攻击者拿到了DNS报文中的ID，伪装DNS服务器回复客户端，引导客户端访问不正确的IP。
• 另一种可能的方式是攻击者侵入了宽带路由器并对终端用户的本地DNS服务器进行篡改，指向攻击者伪造的本地DNS服务器，进而通过控制本地的DNS服务器返回错误的IP信息，进行域名劫持。

如何解决DNS劫持？

• 在终端上手动配置DNS服务器
  （28） 一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？
  （29） 对称密码和非对称密码体系
  （30） 数字证书的了解（高频）
  （31） 客户端为什么信任第三方证书
  （32） RSA加密算法，MD5原理（MD5不算加密算法）
  （33） 单条记录高并发访问的优化
  （34） 介绍一下ping的过程，分别用到了哪些协议
  （35） TCP/IP的分片粘包过程
  （36） 有没有抓过TCP包，描述一下
  （37） 一个ip配置多个域名，靠什么识别？
  （38） 服务器攻击（DDos攻击）