admin 管理员组

文章数量: 887021

计算机网络

  • （1） OSI参考模型
  • （2）以太网
  • （3）ARP协议的作用、简要原理
  • （4）建立TCP服务器的各个系统调用
  • （5）继上一题，说明socket网络编程有哪些系统调用？其中close是一次就能直接关闭的吗，半关闭状态是怎么产生的？
  • （6）connect和accept发生在三次握手的哪个阶段
  • （7） 对路由协议的了解与介绍。内部网关协议IGP包括RIP，OSPF，和外部网关协议EGP和BGP.
  • （8） 路由协议所使用的算法。
  • （9）什么是RIP (Routing Information Protocol, 距离矢量路由协议)? 算法是什么？
  • （10）路由表的项目包括哪些
  • （11） TCP和UDP的区别
  • （12） TCP和UDP相关的协议与端口号
  • （13） IP、TCP、UDP首部详解
  • （14）IP地址和MAC地址
  • （15）网页解析的过程与实现方法
  • （16）在浏览器中输入URL后执行的全部过程（如www.baidu）
  • （17）网络层分片的原因与具体实现
  • （18）TCP的三次握手与四次挥手的详细介绍 （TCP连接建立与断开是热门问题）
  • （19）TCP握手以及每一次握手客户端和服务器端处于哪个状态（11种状态）
  • （20）为什么使用三次握手，两次握手可不可以？
  • （21）TIME_WAIT的意义（为什么要等于2MSL）
  • （22）TCP如何保证的可靠传输？
  • （23）流量控制的介绍，采用滑动窗口会有什么问题（死锁可能，糊涂窗口综合征）？
  • （24）tcp滑动窗口协议
  • （25）拥塞控制和流量控制的区别
  • （26）TCP的拥塞控制是怎么实现的？
  • （27）http协议与TCP联系
  • （28）http/1.0和http/1.1的区别
  • （29）HTTP有几种请求方式
  • （30）HTTP请求报文和响应报文格式，请求行和响应行都有什么
  • （31）http的请求方法有哪些？get和post的区别。
  • （32） http的状态码
  • （33）http和https的区别，由http升级为https需要做哪些操作
  • （34）https的具体实现，怎么确保安全性
  • （35）网站从http升级为https需要什么？
  • （36） http中浏览器一个URL的流程，这个过程中浏览器做了什么，URL包括哪三个部分？
  • （37）给一个网址先解析什么后解析什么（域名解析顺序）？
  • （38）Https握手过程
  • （39）HTTP劫持和DNS劫持
  • （40）跨域
  • （41） 一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？
  • （42） 对称密码和非对称密码体系
  • （43）什么是数字签名？
  • （44）什么是数字证书？
  • （45）客户端为什么信任第三方证书
  • （46）RSA加密算法，MD5原理（MD5不算加密算法）
  • （47） 单条记录高并发访问的优化
  • （48） Ping的过程，分别用到了哪些协议
  • （49）TCP/IP的分片粘包过程
  • （52） 服务器攻击（DDos攻击）
  • （53）DNS的查找过程（应用层）
  • （54）谈谈你对域名缓存的了解？
  • （55）DNS为什么使用UDP协议、DNS什么时候使用TCP协议
  • （56）什么是静态资源、什么是动态资源？
  • （57）动态主机配置协议DHCP的过程
  • （58）什么是NAT (Network Address Translation, 网络地址转换)？
  • （59）集线器、网桥、交换机、路由器
  • （60）MSL、TTL、RTT 是什么？
  • （61）LAN、WAN、WLAN、VLAN和VPN的区别
  • （62）谈谈你对 ARQ 协议的理解？
  • （63）连续 ARQ 协议
  • （64）谈谈你对停止等待协议CSMA/CD的理解？
  • 设计题目：
    • 在面对未知的流量暴增，可以预先怎么处理
    • 什么是RPC协议？HTTP和RPC的区别
    • 网站出现504错误的解决方法
    • 网站出现502错误的解决方法
    • 输入 www.baidu ，怎么变成 https://www.baidu 的，怎么确定用HTTP还是HTTPS
    • 发送窗口的大小，如何最大利用带宽，假设延迟100ms，发送端10Mb/s，接收端100Mb/s.
    • cookie 与 session
    • udp如何实现可靠性传输？
    • 微信扫码登录网页实现原理
    • 布隆过滤器的原理

（1） OSI参考模型

1、物理层：物理层处于OSI参考模型的最低层。物理层的任务就是透明地传送比特流。在物理层上所传数据的单位是比特。传递信息所利用的一些物理媒体，如双绞线、同轴电缆、光缆等，并不在物理层之内而是在物理层的下面。因此也有人把物理媒体当做第 0 层。
2、数据链路层：当发送数据时，数据链路层的任务是将在网络层交下来的 IP 数据报组装成帧，在两个相邻结点间的链路上传送以帧为单位的数据。每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制、以及流量控制信息等）。控制信息使接收端能够知道—个帧从哪个比特开始和到哪个比特结束。控制信息还使接收端能够检测到所收到的帧中有无差错。
3、网络层：网络层负责为分组交换网上的不同主机提供通信。在发送数据时，网络层将运输层产生的报文段或用户数据报封装成分组或包进行传送。在 TCP/IP 体系中，分组也叫作 IP 数据报，或简称为数据报。网络层的另一个任务就是要选择合适的路由，使源主机运输层所传下来的分组能够交付到目的主机。。
4、传输层：传输层的任务就是负责主机中两个进程之间的通信。因特网的传输层可使用两种不同协议：即面向连接的传输控制协议 TCP，和无连接的用户数据报协议 UDP。面向连接的服务能够提供可靠的交付，但无连接服务则不保证提供可靠的交付，它只是“尽最大努力交付”。这两种服务方式都很有用，备有其优缺点。在分组交换网内的各个交换结点机都没有传输层。
5、会话层：会话层的主要目的是组织同步的两个会话用户之间的对话，并管理数据的交换。
6、表示层：表示层主要用于处理两个通信系统间信息交换的表示方式，它包括数据格式变换、数据加密与解密、数据压缩与恢复等功能。
7、应用层：应用层是体系结构中的最高层。**应用层确定进程之间通信的性质以满足用户的需要。这里的进程就是指正在运行的程序。**应用层不仅要提供应用进程所需要的信息交换和远地操作，而且还要作为互相作用的应用进程的用户代理，来完成一些为进行语义上有意义的信息交换所必须的功能。应用层直接为用户的应用进程提供服务

（2）以太网

1.1 以太网：不可靠、无连接服务
无连接(connectionless):发送帧的网卡与接收帧的网卡间没有"握手”过程

不可靠(unreliable):接收网卡不向发送网卡进行确认，差错帧直接丢弃，丢弃帧中的数据恢复依靠高层协议(e.g., TCP)，否则，发生数据丢失

以太网的MAC协议:采用二进制指数退避算法的CSMA/CD（载波监听多路访问/冲突检测）

NIC从网络层接收数据报
创建数据帧。
监听信道:
如果NIC监听到信道空闲，则开始发送帧;
如果NIC监听到信道忙， 则一直等待到信道空闲，然后发送帧。
NIC发送完整个帧，而没有检测到其他结点的数据发送，则NIC确认帧发 送成功!
如果NIC检测到其他结点传输数据，则中止发送，并发送堵塞信号(jam signal)
中止发送后，NIC进入二进制指数退避:
■第m次连续冲突后:
●取n = min(m, 10)
●NIC从{0,1,2， … 2"-1}中随机选择一个数K
●NIC等待K*512比特的传输延迟时间，再返回第2步
■连续冲突次数越多，平均等待时间越长。
1.2 以太网帧格式

前导码：
0,1组成，7个字节，每个字节都为10101010 （0xAA）
是以太网帧的开始，用于发送端和接收端的时钟同步。
最后一个字节是起始帧分隔符（SFD, Start Frame Delimiter）时，SFD的固定值0xAB，10101011。就是说前面都是10101010，检测到10101011就说明要开始发送了。

基本帧格式：
包括48位（6字节）的目的**MAC地址（DST）和源MAC地址（SRC）**字段。

类型：保存的是上层网络协议的类型，TCP/IP网络使用的常见值包括IPv4（0x0800)、IPv6（0x86DD）和ARP(0x0806）。

数据：指上层协议载荷，最小是46字节。

FCS（帧检测序列）

总结：一般是有前导码、SFD、目标MAC地址、源MAC地址、类型、标签、数据、FCS（帧检测序列）

（3）ARP协议的作用、简要原理

ARP协议 Address Resolution Protocol，即地址解析协议， 用于实现从 IP 地址到 MAC 地址的映 射，即询问目标IP对应的MAC地址
1、每台主机都会在自己的ARP缓冲区中建立一个 ARP列表，以表示IP地址和MAC地址的对应关系。
2、当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址。
如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。
3、此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。
4、如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中。
5、如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址。
6、源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。
7、如果源主机一直没有收到ARP响应数据包，表示ARP查询失败

为什么要用ARP协议：
OSI把网络分成7层，每层之间不直接交流，只有特定接口有交流。 IP在第三层网络层，MAC地址工作在第二层数据链路层。协议发包时需要封装IP地址和 MAC地址，但只知道IP，又不能跨层直接找，所以得用ARP协议的服务帮助获取目的节点 的MAC地址

ARP协议注意到的问题：

ARP 是解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题。

如果所要找的主机和源主机不在同一个局域网上，那么就要通过 ARP 找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送给这个路由器，让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。

（4）建立TCP服务器的各个系统调用

客户端和服务器进行通信的过程如下：

首先运行的一定是服务器，在WinSock 环境下，

  1. 首先会调用WSAStartup函数，
  2. 再调用socket函数创建套接字，
  3. 再调用bind函数为套接字绑定本地地址和端口号，
  4. 再调用listen将套接字设为监听模式
  5. 再调用accept函数等待客户请求到来

再看客户端，在在WinSock 环境下，
首先会调用WSAStartup函数，
同样调用socket函数创建套接字，
（注意，客户端一般是不需要调用blind函数的，因为客户端发送连接的时候，内核会自动分配一个端口号给它。）
再调用connect函数向服务器发送连接请求

此时服务器的accept函数发现请求到来，返回一个新的对用于此次连接的套接字，并且通过这个新的套接字和客户端进行连接确认

此时连接建立，服务器调用rece函数，通过这个新创建的套接字接收客户端的数据，客户端调用send函数，利用已连接的套接字向服务器发送一个request

客户端再调用rece函数接收服务器通过send函数发回的响应

假如客户端认为这次通信到此结束了，就调用closesocket函数将这个套接字释放掉，
如果服务器也认为这个连接结束，也会调用closesocket函数释放这个新创建的套接字（注意是ns，s还在）

客户端最后会调用WSADtartup函数清除
而客户端会再次回到accept函数，继续等待下一个客户端的连接请求。

如果服务器要终止，也会调用WSADtartup函数

首先客户端调用connect函数，函数进入阻塞状态，发送syn给服务器端，服务器端响应，accept请求进入阻塞状态，返回ack,syn给客户端，客户端收到，此时connect阻塞返回，connect过程结束，发生在1 2次握手，然后返回ack给服务器端，服务器端收到请求，此时accept返回，服务器收到，accept发生在1 2 3次握手。


所以 建立TCP服务器的各个系统调用如下：

服务器调用主要包括：socket()，bind()，listen()，accept()，recv()，send()以及close()。
建立TCP客户端时函数调用主要为：socket()，connect()，send()，recv()以及close()。


（5）继上一题，说明socket网络编程有哪些系统调用？其中close是一次就能直接关闭的吗，半关闭状态是怎么产生的？

close并不是一次就能直接关闭，调用close只能将套接字的引用计数减1，可能其他进程还在使用这个套接字，所以并不是直接关闭

同时在TCP协议中，发送关闭请求时，需要对方回复确认请求，否则不能确认，就会造成一个半关闭的状态，这个时候可以接收，不能发送。

半关闭的定义：
TCP提供了连接的一端在结束它的发送后，还能接收来自另一端发来的数据的能力，这就是TCP的半关闭。
当一方关闭发送通道后，仍可接受另一方发送过来的数据，这样的情况叫“半关闭”。（拆除TCP连接是：你关闭你的发送通道，我关闭我的发送通道）。

调用shutdown，shutdown的第二个参数为SHUT_WR时，为半关闭。shutdow函数可以立即关闭进程，不用考虑套接字的引用计数


（6）connect和accept发生在三次握手的哪个阶段

从这个图上看，首先客户端调用connect函数，函数进入阻塞状态，发送syn给服务器端，服务器端响应，accept请求进入阻塞状态，返回ack,syn给客户端，客户端收到，此时connect阻塞返回，connect过程结束，发生在1 2次握手，然后返回ack给服务器端，服务器端收到请求，此时accept返回，服务器收到，accept发生在1 2 3次握手。


（7） 对路由协议的了解与介绍。内部网关协议IGP包括RIP，OSPF，和外部网关协议EGP和BGP.

RIP：基于距离向量的路由协议，通过计算距离来选择路由的路径
OSPF：基于链路状态型的路由，给每一个路径有一个权重，并计算路径的代价最小值，选择这条路径
EGP：外部网关协议
BGP：一种常见的外部网关协议，一种矢量的路由协议，它通过维护IP路由表或‘前缀’表来实现自治系（AS）之间的可达性。


（8） 路由协议所使用的算法。

静态路由和动态路由，静态路由用于局域网，内部网络，动态路由用于大型的交换式路由


（9）什么是RIP (Routing Information Protocol, 距离矢量路由协议)? 算法是什么？

每个路由器维护一张表，记录该路由器到其它网络的”跳数“，路由器到与其直接连接的网络的跳数是1，每多经过一个路由器跳数就加1；更新该表时和相邻路由器交换路由信息；路由器允许一个路径最多包含15个路由器，如果跳数为16，则不可达。交付数据报时优先选取距离最短的路径。


（10）路由表的项目包括哪些

目的网络号
掩码
出接口
下一跳地址
度量值
管理距离


（11） TCP和UDP的区别

连接
TCP 是面向连接的传输层协议，即传输数据之前必须先建立好连接。
UDP 无连接。


2） 服务方式
TCP 是点对点的两点间服务，即一条 TCP 连接只能有两个端点；
UDP 支持一对一，一对多，多对一，多对多的交互通信。


3） 可靠性
TCP 是可靠交付：无差错，不丢失，不重复，按序到达。
UDP 是尽最大努力交付，不保证可靠交付。


4）拥塞控制，流量控制
TCP 有拥塞控制和流量控制保证数据传输的安全性。
UDP 没有拥塞控制，网络拥塞不会影响源主机的发送效率。


5） 报文长度
TCP 是动态报文长度，即 TCP 报文长度是根据接收方的窗口大小和当前网络拥塞情况决的。
UDP 面向报文，不合并，不拆分，保留上面传下来报文的边界。


6) 首部开销
TCP 首部开销大，首部 20 个字节。
UDP 首部开销小，8 字节。（源端口，目的端口，数据长度，校验和）


2）TCP 和 UDP 适用场景从特点上我们已经知道，TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定
若通信数据完整性需让位与通信实时性，则应该选用 TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。


QQ使用的那种传输协议？
QQ这类的即时通信应用使用的较多的UDP协议，它们对网络延时的要求较高，但是为了提高数据的安全性，我认为可能对UDP进行了封装（在应用层增加了UDP应答包），这也是UDP的优势一方面的体现，他提供了较为自由的输出方式，我们根据自己的优化需要在使用UDP的时候在应用层进行封装。

UDP的优势在哪？
现如今我们的网络质量越来越好，随着网速的提升，一定程度上降低了UDP数据的丢包率，如果使用在应用层能实现重传，就能保证传输的可靠性。

TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，频繁的握手过程，由于TCP内置的系统协议栈，极难对其进行改进。


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

端口号

TCP和UDP分别对应的常见应用层协议
1). TCP对应的应用层协议
FTP（21）：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
Telnet（23）：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。
SMTP（25）：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
POP3（110）：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
HTTP（80）：从Web服务器传输超文本到本地浏览器的传送协议。


2). UDP对应的应用层协议
DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

（13） IP、TCP、UDP首部详解

IP首部：

1、第一个4字节（也就是第一行）：
（1）版本号（Version），4位；用于标识IP协议版本，IPv4是0100，IPv6是0110，也就是二进制的4和6。
（2）首部长度（Internet Header Length），4位；用于标识首部的长度，单位为4字节，所以首部长度最大值为：(2^4 - 1) * 4 = 60字节，但一般只推荐使用20字节的固定长度。
（3）服务类型（Type Of Service），8位；用于标识IP包的优先级，但现在并未使用。
（4）总长度（Total Length），16位；标识IP数据报的总长度，最大为：2^16 -1 = 65535字节。
2、第二个四字节：
（1）标识（Identification），16位；用于标识IP数据报，如果因为数据链路层帧数据段长度限制（也就是MTU，支持的最大传输单元），IP数据报需要进行分片发送，则每个分片的IP数据报标识都是一致的。
（2）标识（Flag），3位，但目前只有2位有意义；最低位为MF，MF=1代表后面还有分片的数据报，MF=0代表当前数据报已是最后的数据报。次低位为DF，DF=1代表不能分片，DF=0代表可以分片。
（3）片偏移（Fragment Offset），13位；代表某个分片在原始数据中的相对位置。
3、第三个四字节：
（1）生存时间（TTL），8位；以前代表IP数据报最大的生存时间，现在标识IP数据报可以经过的路由器数。
（2）协议（Protocol），8位；代表上层传输层协议的类型，1代表ICMP，2代表IGMP，6代表TCP，17代表UDP。
（3）校验和（Header Checksum），16位；用于验证数据完整性，计算方法为，首先将校验和位置零，然后将每16位二进制反码求和即为校验和，最后写入校验和位置。
4、第四个四字节：源IP地址
5、第五个四字节：目的IP地址
二、TCP首部

1、第一个4字节：
（1）源端口，16位；发送数据的源进程端口
（2）目的端口，16位；接收数据的进程端口
2、第二个4字节与第三个4字节
（1）序号，32位；代表当前TCP数据段第一个字节占整个字节流的相对位置；
（2）确认号，32位；代表接收端希望接收的数据序号，为上次接收到数据报的序号+1，当ACK标志位为1时才生效。
3、第四个4字节：
（1）数据偏移，4位；实际代表TCP首部长度，最大为60字节。
（2）6个标志位，每个标志位1位；
SYN，为同步标志，用于数据同步；
ACK，为确认序号，ACK=1时确认号才有效；
FIN，为结束序号，用于发送端提出断开连接；
URG，为紧急序号，URG=1是紧急指针有效；
PSH，指示接收方立即将数据提交给应用层，而不是等待缓冲区满；
RST，重置连接。
（3）窗口值，16位；标识接收方可接受的数据字节数。详解可参看：http://wwwblogs/woaiyy/p/3554182.html
4、第五个4字节
（1）校验和，16位；用于检验数据完整性。
（2）紧急指针，16位；只有当URG标识位为1时，紧急指针才有效。紧急指针的值与序号的相加值为紧急数据的最后一个字节位置。用于发送紧急数据。
三、UDP首部

（14）IP地址和MAC地址

MAC地址是一个硬件地址，用来定义网络设备的位置，主要由数据链路层负责。而IP地址是IP协议提供的一种统一的地址格式，为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异

MAC Address，Media Access Control Address，亦称为EHA（Ethernet Hardware Address）、硬件地址、物理地址（Physical Address）。在OSI节层模型中，属于第二层链路层概念。一个MAC地址唯一指定一台设备，全球唯一，并且通常烧写在ROM中。
组成
MAC地址如下图所示，其前3字节表示厂商识别码OUI（Organizationally Unique Identifier），由IEEE的注册管理机构给不同厂家分配的代码，区分不同的厂家。后3字节由厂家自行分配。所以，可以保证全世界不会有相同的MAC地址。
不过也会有特例，（不在同一个数据链路MAC地址可以不同，虚拟机通过虚拟软件设置MAC地址给虚拟网卡使用），但是全球通信设备的设计前提都是有唯一的MAC地址。

MAC地址最高字节（MSB）的低第二位（LSb）表示这个MAC地址是全局的还是本地的，即U/L（Universal/Local）位，如果为0，表示是全局地址。所有的OUI这一位都是0。

MAC地址最高字节（MSB）的低第一位(LSb），表示这个MAC地址是单播还是多播。0表示单播。

（15）网页解析的过程与实现方法

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

**第一步：浏览器输入域名
浏览器会把输入的域名解析成对应的IP，**其过程如下：
1.查找浏览器缓存：因为浏览器一般会缓存DNS记录一段时间，不同浏览器的时间可能不一样，一般2-30分钟不等，浏览器去查找这些缓存，如果有缓存，直接返回IP，否则下一步。

2.查找系统缓存：浏览器缓存中找不到IP之后，浏览器会进行系统调用（windows中是gethostbyname），查找本机的hosts文件，如果找到，直接返回IP，否则下一步。

3.查找路由器缓存：如果1,2步都查询无果，则需要借助网络，路由器一般都有自己的DNS缓存，将前面的请求发给路由器，查找ISP 服务商缓存 DNS的服务器，如果查找到IP则直接返回，没有的话继续查找。

4.递归查询：如果以上步骤还找不到，则ISP的DNS服务器就会进行递归查询，所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）

5.迭代查询：本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地域名服务器自己进行后续的查询。（而不是替代本地域名服务器进行后续查询）。
本例子中：根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns的IP地址。本地域名服务器向顶级域名服务器dns进行查询。顶级域名服务器dns告诉本地域名服务器，下一次应查询的权限域名服务器dns.csdn的IP地址。本地域名服务器向权限域名服务器dns.csdn进行查询。权限域名服务器dns.csdn告诉本地域名服务器，所查询的主机www.csdn的IP地址。本地域名服务器最后把结果告诉主机。

第三步：浏览器与目标服务器建立TCP连接
1.主机浏览器通过DNS解析得到了目标服务器的IP地址后，与服务器建立TCP连接。

2.TCP3次握手连接：浏览器所在的客户机向服务器发出连接请求报文（SYN标志为1）；服务器接收报文后，同意建立连接，向客户机发出确认报文（SYN，ACK标志位均为1）；客户机接收到确认报文后，再次向服务器发出报文，确认已接收到确认报文；此处客户机与服务器之间的TCP连接建立完成，开始通信。

第四步：浏览器通过http协议发送请求
浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL，也就是http://www.csdn/ ，KeepAlive，长连接，还有User-Agent用户浏览器操作系统信息，编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip，压缩之后传输html文件。Cookies如果是首次访问，会提示服务器建立用户缓存信息，如果不是，可以利用Cookies对应键值，找到相应缓存，缓存里面存放着用户名，密码和一些用户设置项。

第五步：某些服务会做永久重定向响应
对于大型网站存在多个主机站点，为了负载均衡或者导入流量，提高SEO排名，往往不会直接返回请求页面，而是重定向。返回的状态码就不是200OK，而是301,302以3开头的重定向码，浏览器在获取了重定向响应后，在响应报文中Location项找到重定向地址，浏览器重新第一步访问即可。
重定向的作用：重定向是为了负载均衡或者导入流量，提高SEO排名。利用一个前端服务器接受请求，然后负载到不同的主机上，可以大大提高站点的业务并发处理能力；重定向也可将多个域名的访问，集中到一个站点；由于baidu，www.baidu会被搜索引擎认为是两个网站，照成每个的链接数都会减少从而降低排名，永久重定向会将两个地址关联起来，搜索引擎会认为是同一个网站，从而提高排名。

第六步：浏览器跟踪重定向地址
当浏览器知道了重定向后最终的访问地址之后，重新发送一个http请求，发送内容同上。

第七步：服务器处理请求
服务器接收到获取请求，然后处理并返回一个响应。

第八步：服务器发出一个HTML响应
返回状态码200 OK，表示服务器可以响应请求，返回报文，由于在报头中Content-type为“text/html”，浏览器以HTML形式呈现，而不是下载文件。

第九步：释放TCP连接

  1. 浏览器所在主机向服务器发出连接释放报文，然后停止发送数据；
  2. 服务器接收到释放报文后发出确认报文，然后将服务器上未传送完的数据发送完；
  3. 服务器数据传输完毕后，向客户机发送连接释放报文；
  4. 客户机接收到报文后，发出确认，然后等待一段时间后，释放TCP连接；

第十步：浏览器显示页面
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了，浏览器接收到返回的数据包，根据浏览器的渲染机制对相应的数据进行渲染。渲染后的数据，进行相应的页面呈现和脚步的交互。

第十一步：浏览器发送获取嵌入在HTML中的其他内容
比如一些样式文件，图片url，js文件url等，浏览器会通过这些url重新发送请求，请求过程依然是HTML读取类似的过程，查询域名，发送请求，重定向等。不过这些静态文件是可以缓存到浏览器中的，有时访问这些文件不需要通过服务器，直接从缓存中取。某些网站也会使用第三方CDN进行托管这些静态文件。

浏览器中输入 URL

浏览器要将 URL 解析为 IP 地址，解析域名就要用到 DNS 协议，首先主机会查询 DNS 的缓存，如果没有就给本地 DNS 发送查询请求。DNS 查询分为两种方式，一种是递归查询，一种是迭代查询。如果是迭代查询，本地的 DNS 服务器，向根域名服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的 IP 地址。DNS 服务器是基于 UDP 的，因此会用到 UDP 协议。

得到 IP 地址后，浏览器就要与服务器建立一个 http 连接。因此要用到 http 协议，http 协议报文格式上面已经提到。http 生成一个 get 请求报文，将该报文传给 TCP 层处理，所以还会用到 TCP 协议。如果采用 https 还会使用 https 协议先对 http 数据进行加密。
TCP 层如果有需要先将 HTTP 数据包分片，分片依据路径 MTU 和 MSS。TCP 的数据包然后会发送给 IP 层，用到 IP协议。IP 层通过路由选路，一跳一跳发送到目的地址。当然在一个网段内的寻址是通过以太网协议实现(也可以是其他物理层协议，比如 PPP，SLIP)，以太网协议需要直到目的 IP 地址的物理地址，有需要 ARP 协议。
其中：
1、DNS 协议，http 协议，https 协议属于应用层应用层是体系结构中的最高层。应用层确定进程之间通信的性质以满足用户的需要。这里的进程就是指正在运行的程序。应用层不仅要提供应用进程所需要的信息交换和远地操作，而且还要作为互相作用的应用进程的用户代理，来完成一些为进行语义上有意义的信息交换所必须的功能。应用层直接为用户的应用进程提供服务。

2、TCP/UDP 属于传输层
传输层的任务就是负责主机中两个进程之间的通信。因特网的传输层可使用两种不同协议：**即面向连接的传输控制协议 TCP，和无连接的用户数据报协议 UDP。**面向连接的服务能够提供可靠的交付，但无连接服务则不保证提供可靠的交付，它只是“尽最大努力交付”。这两种服务方式都很有用，备有其优缺点。在分组交换网内的各个交换结点机都没有传输层。

3、IP 协议，ARP 协议属于网络层
**网络层负责为分组交换网上的不同主机提供通信。**在发送数据时，网络层将运输层产生的报文段或用户数据报封装成分组或包进行传送。在 TCP/IP 体系中，分组也叫作 IP 数据报，或简称为数据报。网络层的另一个任务就是要选择合适的路由，使源主机运输层所传下来的分组能够交付到目的主机。

4、数据链路层
**当发送数据时，数据链路层的任务是将在网络层交下来的 IP 数据报组装成帧，在两个相邻结点间的链路上传送以帧为单位的数据。**每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制、以及流量控制信息等）。控制信息使接收端能够知道—个帧从哪个比特开始和到哪个比特结束。控制信息还使接收端能够检测到所收到的帧中有无差错。

5、物理层
**物理层的任务就是透明地传送比特流。**在物理层上所传数据的单位是比特。传递信息所利用的一些物理媒体，如双绞线、同轴电缆、光缆等，并不在物理层之内而是在物理层的下面。因此也有人把物理媒体当做第 0 层。

（17）网络层分片的原因与具体实现

不同的数据链路层的最大传输单位（MTU, Maximun Transimission Unit)不同，以太网的MTU是1500B，FDDI是4352个字节，ATM是9180字节，所以只能在线路上传输比包长还要小的MTU，但是IP的上一层可能会要求传比这些MTU更多字节的数据，所以IP进行分片处理，将较大的IP包分成多个较小的IP包。

传输层
MSS（最大分段大小）：是TCP的限制，双方可以协商，往往是减去两个头部，40B。

UDP不分段，靠IP分片

原因：每一种物理网络都会规定链路层数据帧的最大传输单位，称为链路层MTU(Maximum Transmission Unit).IP协议在传输数据包时，若IP数据报加上数据帧头部后长度大于MTU，则将数据报文分为若干分片进行传输，并在目标系统中进行重组。比如说，在以太网环境中可传输最大IP报文大小（MTU）为1500字节。如果要传输的数据帧大小超过1500字节，即IP数据报长度大于1472(1500-20-8=1472，普通数据报)字节，则需要分片之后进行传输。

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

最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。
一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。
第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。
第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。
第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。


可以采用四次握手吗？为什么
可以。但是会降低传输的效率。 四次握手是指：第二次握手：Server只发送ACK和acknowledge number；而Server的SYN和初始序列号在第三次握手时发送；原来协议中的第三次握手变为第四次握手。出于优化目的，四次握手中的二、三可以合并。
第三次握手中，如果客户端的ACK未送达服务器，会怎样？ Server端： 1、由于Server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。 Client端，两种情况：
  • 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK
    number，进入 establish 状态
  • 在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

初始序列号是什么？
TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号（Initial Sequence Number，ISN），比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002…三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时，B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是2001，就说明编号为1001-2000的数据已经被B成功接受



四次挥手：

第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。

（4）为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。


如果第二次挥手时服务器的ACK没有送达客户端，会怎样？
客户端没有收到ACK确认，会重新发送FIN请求。


（6）保活计时器的作用？
除时间等待计时器外，TCP 还有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。


什么是TIME_WAIT状态，为什么要有这个状态

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。



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


11种状态：
1)、LISTEN:首先服务端需要打开一个socket进行监听，状态为LISTEN.

2)、SYN_SENT:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT.

3)、SYN_RECV:服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN. 之后状态置为SYN_RECV

4)、ESTABLISHED: 代表一个打开的连接，双方可以进行或已经在数据交互了。

5)、FIN_WAIT1:主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态.

6)、CLOSE_WAIT:被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT.

7)、FIN_WAIT2:主动关闭端接到ACK后，就进入了FIN-WAIT-2 .

8)、LAST_ACK:被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK . /

9)、TIME_WAIT:在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。

10)、CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报 文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

11)、CLOSED: 被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束

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

为什么A还要发送一次确认呢？可以二次握手吗？
答：主要为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。如A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，A工发出了两个连接请求报文段，其中第一个丢失，第二个到达了B，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接，不采用三次握手，只要B发出确认，就建立新的连接了，此时A不理睬B的确认且不发送数据，则B一致等待A发送数据，浪费资源。

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
第一次握手：Client 什么都不能确认；Server 确认了对方发送正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己接收正常，对方发送正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送接收正常
所以三次握手就能确认双发收发功能都正常，缺一不可。

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

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2
两个理由：1）保证A发送的最后一个ACK报文段能够到达B。2）防止“已失效的连接请求报文段”出现在本连接中。
这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。

2）A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

（22）TCP如何保证的可靠传输？

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
如何校验：校验和
发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。

对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；

丢弃重复数据：对于重复数据，能够丢弃重复数据；

  1. 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
  2. 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
  3. 丢弃重复数据：对于重复数据，能够丢弃重复数据；
  4. 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
  5. 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
  6. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

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

主要介绍再接收端和发送端速率不匹配的状况下，TCP协议栈滑动窗口动态调整机制产生的一种问题 叫糊涂窗口综合症，

这个问题可以归结为小包的问题，就是由于发送端和接收端上的处理不一致，导致网络上产生很多的小包，之前也介绍过避免网络上产生过多小包的措施，比如Nagle算法。在滑动窗口机制下，如果发送端和接收端速率很不一致，也会产生这种比较犯傻的状态：发送方发送的数据，只要一个大大的头部，携带数据很少。

对于接收端来讲，如果接收很慢，一次接收1个字节或者几个字节，这个时候接收端 缓冲区很快就会被填满，然后窗口通告为0字节，这个时候发送端停止发送，应用程序收上去1个字节后，发出窗口通告为1字节，发送方收到通告之后，发出1个字节的数据，这样周而复始，传输效率会非常低。

同时如果发送端程序一次发送一个字节，虽然窗口足够大，但是发送仍是一个字节一个字节的传输，效率很低

死锁状态
（1）概述：
当接收端向发送端发送零窗口报文段后不久，接收端的接收缓存又有了一些存储空间，于是接收端向发送端发送了Windows size = 2的报文段，然而这个报文段在传输过程中丢失了。发送端一直等待收到接收端发送的非零窗口的通知，而接收端一直等待发送端发送数据，这样就死锁了。
（2）解决方法
TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
糊涂窗口综合症（接收端糊涂，网络上小包泛滥的原因之一）

糊涂窗口综合症（接收端糊涂，网络上小包泛滥的原因之一）

（1）概述：

TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存区中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节的话），然后，发送方又发来1字节的数据（发送方的IP数据报是41字节），接收方发回确认，仍将窗口设置为1个字节，这样，网络效率就会很低

（2）解决办法
a.你糊涂我不糊涂法。即Nagle算法。
可让接收方等待一段时间，使得或者 接收缓存已有足够的空间容纳一个 最长的报文段，或者等到接收方缓存已有一半的空闲空间。只要出现这两种情况，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报文积累为足够大的报文段或达到接收方缓存的空间的一半大小。
b.治疗接收端的糊涂（其中一种机制是延迟ACK（还有其它机制，例如不发送小窗口通告等））

      对于接收方而言， 延迟ACK可以拖延ACK发送时间，进而延迟窗口通告，在这段时间内，接收窗口有机会进一步放大

      对于发送方而言， 不理会接收端的小窗口通告等于说不马上1发送小包，小包有时间积累成大包

（24）tcp滑动窗口协议

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window（窗口大小单位是字节），接受窗口的大小是根据自己的资源情况动态调整的，在返回ACK时将接受窗口大小放在TCP报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小，只有当发送方发送并收到确认之后，才能将发送窗口右移。
发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。


什么是零窗口（接收窗口为0时会怎样？）
如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

（25）拥塞控制和流量控制的区别

流量控制：利用滑动窗口实现流量控制，如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

拥塞控制：拥塞控制就是为了防止过多的数据注入到网络中,全局网络的拥塞情况，如果有发生丢包则通过拥塞控制减小窗口，确定出合适的拥塞窗口。

（26）TCP的拥塞控制是怎么实现的？

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。

拥塞控制主要由四个算法组成：慢启动（Slow Start）、拥塞避免（Congestion voidance）、快重传 （Fast Retransmit）、快恢复（Fast Recovery）

  1. 慢启动：刚开始发送数据时，先把拥塞窗口（congestion window）设置为一个最大报文段MSS的数值，每收到一个新的确认报文之后，就把拥塞窗口加1个MSS。这样每经过一个传输轮次（或者说是每经过一个往返时间RTT），拥塞窗口的大小就会加倍

  2. 拥塞避免：当拥塞窗口的大小达到慢开始门限(slow start threshold)时，开始执行拥塞避免算法，拥塞窗口大小不再指数增加，而是线性增加，即每经过一个传输轮次只增加1MSS.

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。（这是不使用快重传的情况）

  1. 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期

  2. 快恢复：当发送方连续收到三个重复确认时，就把慢开始门限减半，然后执行拥塞避免算法。不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。


    也有的快重传是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3*MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中。可见现在网络中减少了三个分组。因此可以适当把拥塞窗口扩大些。

（27）http协议与TCP联系

TCP协议对应于传输层，而HTTP协议对应于应用层

TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。
关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。”

TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

（28）http/1.0和http/1.1的区别

1、http1.0 与 http1.1的区别

  • HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器每次都需要与服务器建立一个TCP连接，服务器完成请求后，立即断开TCP连接，也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应过程与第一次被访问时是相同的。举例在收到的HTML文档后，文档中有10个图片，每个图片都要重新再次建立连接获取，所以网速较慢的时候，我们有时会看到先出现网页，每个图片再逐一出现。
    这样做的好处：简化了服务器的设计，是服务器更容易支持大量并发的HTTP请求
    这样做的缺点：每请求一个文档就要有两倍RTT的开销 ，详细过程：HTTP协议首先要和服务器建立TCP连接，这需要三次握手，当三次握手的前两部分经过一个RTT完成后，客户就把HTTP请求报文作为第三次握手的第三个报文的数据发送给万维网服务器，服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。每个请求文档花费两倍的RTT时间
    HTTP/1.1支持持续连接和流水线方式
    持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这条持续的连接并不局限于传输同一个页面上链接的文档，而是只要文档在同一个服务器上就可以通过这条持续的连接传送。
    流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

  • 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
    HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

  • 带宽优化
    HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。又比如下载大文件时不支持断点续传功能，在发生断连后不得不重新下载完整的包。
    HTTP/1.1中在请求消息中引入了range头域，它支持只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。

  • HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）

HTTP/1.0 - 构建可扩展性

  • 在请求中新增了协议版本信息

  • 引入了 HTTP 头的概念

  • 在响应中新增了状态码

  • 默认使用短连接：浏览器每请求一个静态资源，就建立一次连接，任务结束就中断连接

HTTP/1.1 - 标准化的协议

  • 默认支持长连接：在一个网页打开期间，所有网络请求都复用同一条已经建立的连接

    Pros：性能更好，节省频繁建立 TCP 连接、慢启动、关闭连接等的时间，整体耗时更短
    Cons：会占用服务器的资源

  • 引入额外的缓存控制机制：如 Entity tag、If-None-Match 等更多可供选择的缓存头

  • 新增了 24 个错误状态响应码，如 409（Conflict）、410（Gone）

  • 引入内容协商，允许通信双方约定语言（Accept-Language）、编码（Accept-Encoding）等

  • 支持响应分块和断点续传

  • 引入管线化（Pipelining）：从前发送请求后需等待并收到响应，才能发送下一个请求，现在允许客户端同时并行发送多个请求**

     Pros：在收到上一个请求的响应之前就可以发出下一个请求，能够节省请求到达服务器的时间，降低通信延迟
 Cons：服务器要遵循 HTTP/1.1 协议，必须按照客户端发送的请求顺序返回响应，可能发生队头阻塞（HOL blocking）——若上一个请求的响应迟迟没有处理完毕，则后面的响应都会被阻塞

  • Host 头，允许不同域名配置在同一个 IP 地址上

  • 长连接、管线化都是为了让请求更短时间内结束

2 HTTP1.1和HTTP2.0的区别
HTTP/2.0 的三大特性：Header 压缩、服务端推送、多路复用。
Header 压缩
HTTP/1.1 每次通信都会携带 Header 信息用于描述资源属性。但 headers 在一系列请求中常常是相似的。HTTP/2.0 中，对于 Header 中相同的数据，不会在每次通信中重新发送，而是采用追加或替换的方式。
具体实现上，HTTP/2.0 在客户端和服务端之间共同维护一个 Header 表，存储之前发送的 key-value 对。Header 表在 HTTP/2.0 的连接期间始终存在。
Header 压缩可以减少每次通信的数据量，提高传输速度。

服务端推送
服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。
服务端根据客户端的请求，提前推送额外的资源给客户端。比如在发送页面 HTML 时主动推送其它 CSS/JS 资源，而不用等到浏览器解析到相应位置，发起请求再响应。
服务端推送可以减轻数据传输的冗余步骤，同时加快页面响应速度，提升用户体验。

多路复用
二进制分帧
HTTP/1.x 使用文本格式传输数据。HTTP/2.0 在将所有传输信息分割为若干个帧，采用二进制格式进行编码。
具体实现上，是在应用层（HTTP）和传输层（TCP）之间增加一个二进制分帧层。每个请求对应一个流，有一个唯一的整数标识符。HTTP/1.x 的报文会被拆分为一个或多个帧，每个帧有序列号，以及自己所述的流的标识符，接收端自行合并。
二进制分帧采用更高效的编码协议，提升了传输效率。同时，二进制分帧也为多路复用提供了基础。

多路复用
HTTP/1.x 有顺序和阻塞约束：
顺序：服务端必须按照客户端请求到来的顺序，串行返回数据
即使 HTTP/1.1 允许通过同一个连接发起多个请求，也无法真正并行传输
阻塞：浏览器会限制每个域名下最多同时发起的 6 个连接，超过该数量的连接会被阻塞，以下是常见的优化方法：
使用多个域名（比如 CDN）来提高浏览器的下载速度
将多个 JS 文件、CSS 文件等打包成一个文件，将多个小图片合并为雪碧图，减少 HTTP 请求数
HTTP/2.0 引入了多路复用，通过同一个连接发起多个请求，服务端可以并行地传输数据。基于二进制分帧层，HTTP/2.0 可以同时交错发送多个消息中的帧，接收端可以根据帧中的流标识符和顺序标识，重新组装数据。
多路复用使用同一个 TCP 连接并发处理同一域名下的所有请求，可以减少 TCP 建立连接带来的时延。此外多路复用代替了 HTTP/1.x 中的顺序和阻塞机制，实现了真正的并行传输，可以避免 HTTP/1.x 中的队头阻塞问题，极大的提高传输效率


（29）HTTP有几种请求方式

HTTP1.0 定义了三种请求方法： GET, POST 和HEAD方法。 HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。


（30）HTTP请求报文和响应报文格式，请求行和响应行都有什么

HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成；
下面对请求报文格式进行简单的分析：
　　请求行：请求行由方法字段、URL 字段 和HTTP 协议版本字段 3 个部分组成，他们之间使用空格隔开。常用的 HTTP 请求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT;
　　● GET：当客户端要从服务器中读取某个资源时，使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的数据部分，回送给客户端，即向服务器请求某个资源。使用GET 方法时，请求参数和对应的值附加在 URL 后面，利用一个问号(“?”)代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。
　　● POST：当客户端给服务器提供信息较多时可以使用POST 方法，POST 方法向服务器提交数据，比如完成表单数据的提交，将数据提交给服务器处理。GET 一般用于获取/查询资源信息，POST 会附带用户数据，一般用于更新资源信息。POST 方法将请求参数封装在HTTP 请求数据中，以名称/值的形式出现，可以传输大量数据;
　　请求头部：请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：
　　● User-Agent：产生请求的浏览器类型;
　　● Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ / ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;
　　● Accept-Language：客户端可接受的自然语言;
　　● Accept-Encoding：客户端可接受的编码压缩格式;
　　● Accept-Charset：可接受的应答的字符集;
　　● Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机;
　　● connection：连接方式(close 或 keepalive);
　　● Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;
　　空行：最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头;
　　请求包体：请求包体不在 GET 方法中使用，而是在POST 方法中使用。POST 方法适用于需要客户填写表单的场合。与请求包体相关的最常使用的是包体类型 Content-Type 和包体长度 Content-Length;
　　

实际上每一行末尾都有\r\n，这里看不到而已

http request

请求行，/表示请求的路径，HTTP/1.1表示协议版本
GET / HTTP/1.1

头部
Accept: image/jpeg, application/x ms- -application, image/gif, application/ xaml+xml，image/pjpeg, applicati
applicati on/vnd. ms-excel, appli cati on/vnd. ms powerpoint, applicati on/msword, */*
Accept -Language: zh-CN
User-Agent: Mozilla/4. 0 (compatible; MSIE 8.0; Windows, NT 6.1; Trident/4. 0; SLCC2; . NET CLR 2. 0.50727; .N, NET CLR 3.0. 30729; Media Center PC 6.0; Tablet PC 2.0) 
Accept -Encoding: gzip， deflate
Host: 192. 168. 159.188:8000
Connection: Keep-Alive
\r\n

请求的实体body

上面是典型的GET请求，若是POST请求的话，就有实体
==========================================================================================
http response

状态行
HTTP/1.1 200 OK
头部
Content -Length: 112 ，
Connection: Keep- -Alive
Content -Type: text/html ,
Server: Muduo

实体
<html><head><title>This is title</title></head><body><h1 >Hello</h1>Now is 201 30613 08:22:04. 213389</body>

HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成
下面对响应报文格式进行简单的分析：
　　状态行：状态行由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成，他们之间使用空格隔开;
　　● 状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：
　　1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;
　　2xx：表示服务器已成功接收到请求并进行处理;
　　3xx：表示服务器要求客户端重定向;
　　4xx：表示客户端的请求有非法内容;
　　5xx：表示服务器未能正常处理客户端的请求而出现意外错误;
　　● 状态码描述文本有如下取值：
　　200 OK：表示客户端请求成功;
　　400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解;
　　401 Unauthonzed：表示请求未经授权该状态代码必须与 WWW-Authenticate 报头域一起使用;
　　403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因;
　　404 Not Found：请求的资源不存在，例如，输入了错误的URL;
　　500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求;
　　503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常;

**响应头部：响应头可能包括：
　　Location：Location响应报头域用于重定向接受者到一个新的位置。**例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源;
　　Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。
　　Vary：指示不可缓存的请求头列表;
　　Connection：连接方式;
　　对于请求来说：close(告诉 WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求);
　　对于响应来说：close(连接已经关闭); keepalive(连接保持着，在等待本次连接的后续请求); Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间(秒);例如：Keep-Alive：300;
　　WWW-Authenticate：WWW-Authenticate响应报头域必须被包含在401 (未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服r务器对其进行验证，就可以发送一个包含了Authorization 报头域的请求;
　　空行：最后一个响应头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。
　　响应包体：服务器返回给客户端的文本信息;
　　

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

概括
对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据)；而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）
2、区别：
1、get 参数通过 url 传递，post 放在 request body 中。
2、get 请求在 url 中传递的参数是有长度限制的，而 post 没有。
3、get 比 post 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
4、get 请求只能进行 url 编码，而 post 支持多种编码方式。
5、get 请求会浏览器主动 cache，而 post 支持多种编码方式。
6、get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。
7、GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
8、GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包

1. GET是幂等的，即读取同一个资源，总是得到相同的数据，POST不是幂等的；
2. GET一般用于从服务器获取资源，而POST有可能改变服务器上的资源；
3. 请求形式上：GET请求的数据附在URL之后，在HTTP请求头中；POST请求的数据在请求体中；
4. 安全性：GET请求可被缓存、收藏、保留到历史记录，且其请求数据明文出现在URL中。POST的参数不会被保存，安全性相对较高；
5. GET只允许ASCII字符，POST对数据类型没有要求，也允许二进制数据；
6. GET的长度有限制（操作系统或者浏览器），而POST数据大小无限制

（32） http的状态码

1开头的http状态码
表示临时响应并需要请求者继续执行操作的状态代码。
100（继续）请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101（切换协议）请求者已要求服务器切换协议，服务器已确认并准备切换。


2开头的http状态码
表示请求成功
200 成功处理了请求，一般情况下都是返回此状态码；
201 请求成功并且服务器创建了新的资源。
202 接受请求但没创建资源；
203 返回另一资源的请求；
204 服务器成功处理了请求，但没有返回任何内容；
205 服务器成功处理了请求，但没有返回任何内容；
206 处理部分请求；

3xx （重定向） 重定向代码，也是常见的代码
300（多种选择）针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301（永久移动）请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302（临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303（查看其他位置）请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304（未修改）自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305（使用代理）请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307（临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4开头的http状态码表示请求出错(客户端出错)
400（Bad Request ） 服务器不理解请求的语法。
401（Unauthorized ） 请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403（Forbidden ） 服务器拒绝请求。
404 （Not Found ） 服务器找不到请求的网页。
405 禁用请求中指定的方法。
406 无法使用请求的内容特性响应请求的网页。
407 此状态代码与 401类似，但指定请求者应当授权使用代理。
408 服务器等候请求时发生超时。
409 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。
410 如果请求的资源已永久删除，服务器就会返回此响应。
411 服务器不接受不含有效内容长度标头字段的请求。
412 服务器未满足请求者在请求中设置的其中一个前提条件。
413 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 请求的 URI（通常为网址）过长，服务器无法处理。
415 请求的格式不受请求页面的支持。
416 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 服务器未满足”期望”请求标头字段的要求。

5开头状态码并不常见，但是我们应该知道
500（服务器内部错误服务器遇到错误，无法完成请求。
501（尚未实施）服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502（Bad Gateway错误网关）服务器作为网关或代理，从上游服务器收到无效响应。
503（服务不可用）服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。
504（Gateway Timeout网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505（HTTP 版本不受支持）服务器不支持请求中所用的 HTTP 协议版本。


（33）http和https的区别，由http升级为https需要做哪些操作

HTTPS的全称是Secure Hypertext Transfer Protocol（安全超文本传输协议），HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。


HTTP协议和HTTPS协议区别如下：
1）HTTP协议是以明文的方式在网络中传输数据，HTTPS运行在SSL(Secure Socket Layer)之上，添加了加密和认证机制，更加安全；
2）HTTPS在TCP三次握手阶段之后，还需要进行SSL 的handshake，协商加密使用的对称密钥
3）HTTPS协议需要服务端申请CA证书，浏览器端安装对应的根证书
4）HTTP协议端口是80，HTTPS协议端口是443


HTTPS优点：
HTTPS传输数据过程中使用密钥进行加密，所以安全性更高
HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器


HTTPS缺点：

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加
HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高


SSL与TLS的区别？
SSL：（Secure Socket Layer，安全套接字层），SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。

http和HTTPS详解

（34）https的具体实现，怎么确保安全性

HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

（35）网站从http升级为https需要什么？

前面说到https加密协议=SSL / TLS+http协议，也就是说，网站从http升级为https的关键就在于SSL证书，网站安装SSL证书之后就可以从http升级为https，进行加密传输，保护网站数据安全了。

（36） http中浏览器一个URL的流程，这个过程中浏览器做了什么，URL包括哪三个部分？

URL（统一资源定位符）包括：协议名，主机名，路径及文件名

  1. 输入一个网址之后，首先浏览器通过查询DNS，查找这个URL的IP地址，（浏览器首先通过查找内部DNS缓存，，查不到依次进行系统DNS缓存，路由器缓存，DNS服务器，一步一步找到并解析IP地址通过层层向 上级DNS服务器查找直到找到对应URL的IP地址）
  2. 得到目标服务器的IP地址及端口号（http 80端口，https 443端口），会调用系统库函数socket，请求一个TCP流套接字。客户端向服务器发送HTTP请求报文
    （1）应用层：客户端发送HTTP请求报文。
    （2）传输层：（加入源端口、目的端口）建立连接。实际发送数据之前，三次握手客户端 和服务器建立起一个TCP连接。
    （3）网络层：（加入IP头）路由寻址。
    （4）数据链路层：（加入frame头）传输数据。
    （5）物理层：物理传输bit。
  3. 服务器端经过物理层→数据链路层→网络层→传输层→应用层，解析请求报文，发送 HTTP响应报文。
  4. 关闭连接，TCP四次挥手。
  5. 客户端解析HTTP响应报文，浏览器开始显示HTML

（37）给一个网址先解析什么后解析什么（域名解析顺序）？

域名分层：从右到左分别为顶级域名、二级域名…最左为主机名（服务器名）。比如 www.baidu的com为顶级域名，email.tsinghua.edu中cn为顶级域名，为中国国 家域名，edu为教育科研部门域名，email为服务器名。

域名解析时，优先查找匹配的子域名，如果子域名存在，则从子域名的配置文件查询解析结 果，如果子域名不存在，就从上一级的配置文件查询结果

（38）Https握手过程

https://blog.csdn/cout__waht/article/details/80859369

  1. 客户端向服务器发送请求，同时发送客户端支持的一套加密规则（包括对称加密、非对称加密、摘要算法）；
  2. 服务器从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥（用于非对称加密），以及证书的颁发机构等信息（证书中的私钥只能用于服务器端进行解密）；
  3. 客户端验证服务器的合法性，包括：证书是否过期，CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配；
  4. 如果证书受信任，浏览器会生成一个随机密钥（用于对称算法），并用服务器提供的公钥加密（采用非对称算法对密钥加密）；使用Hash算法对握手消息进行摘要计算，并对摘要使用之前产生的密钥加密（对称算法）；将加密后的随机密钥和摘要一起发送给服务器；
  5. 服务器使用自己的私钥解密，得到对称加密的密钥，用这个密钥解密出Hash摘要值，并验证握手消息是否一致；如果一致，服务器使用对称加密的密钥加密握手消息发给浏览器；
  6. 浏览器解密并验证摘要，若一致，则握手结束。之后的数据传送都使用对称加密的密钥进行加密


    总结：非对称加密算法用于在握手过程中加密生成的密码；对称加密算法用于对真正传输的数据进行加密；HASH算法用于验证数据的完整性。

注意https加密是在传输层

https报文在被包装成tcp报文的时候完成加密的过程，无论是https的header域也好， body域也罢都是会被加密的。 当使用tcpdump或者wireshark之类的tcp层工具抓包，获取是加密的内容，而如果用 应用层抓包，使用Charels(Mac)、Fildder(Windows)抓包工具，那当然看到是明文的。

（39）HTTP劫持和DNS劫持

简单介绍一下HTTP劫持和DNS劫持的概念，也就是运营商通过某些方式篡改了用户正常访问的网页，插入广告或者其他一些杂七杂八的东西。

首先对运营商的劫持行为做一些分析，他们的目的无非就是赚钱，而赚钱的方式有两种：

1、对正常网站加入额外的广告，这包括网页内浮层或弹出广告窗口；

2、针对一些广告联盟或带推广链接的网站，加入推广尾巴。例如普通访问百度首页，被前置跳转为http://www.baidu/?tn=90509114_hao_pg

在具体的做法上，一般分为DNS劫持和HTTP劫持。

DNS劫持：
一般而言，用户上网的DNS服务器都是运营商分配的，所以，在这个节点上，运营商可以为所欲为。

例如，访问http://jiankang.qq/index.html，正常DNS应该返回腾讯的ip，而DNS劫持后，会返回一个运营商的中间服务器ip。访问该服务器会一致性的返回302，让用户浏览器跳转到预处理好的带广告的网页，在该网页中再通过iframe打开用户原来访问的地址。

HTTP劫持：
在运营商的路由器节点上，设置协议检测，一旦发现是HTTP请求，而且是html类型请求，则拦截处理。后续做法往往分为2种，
1种是类似DNS劫持返回302让用户浏览器跳转到另外的地址，
还有1种是在服务器返回的HTML数据中插入js或dom节点（广告）。

处理办法：

1、先对外网做检测，上报被劫持的情况。
页面广告可能通过iframe方式，也可以通过dom节点方式，需要在首页检查这两种情况。

2、针对被iframe加载的情况，需要先找到运营商设置的劫持规律。
在iframe中的网页能正常打开，而不是又被拦截加iframe，可能是因为请求的url上或cookie上运营商做了标记。我们可以利用这个规则，躲过劫持。

3、针对注入dom节点的情况，初始化时做检查，而且后续dom注入也做检查。可以检查dom中是否含有白名单以外的http链接，如果有，就可以判定为http劫持。

4、在前端以外的处理办法还有
a) 终端拦截所有返回包，判断ip来自黑名单（劫持的中间ip）则丢弃返回包。

这种做法的原因是，运营商劫持http请求后，并不是完全丢弃请求包，而是做了复制，一份继续发给目标服务器，另外一份做劫持处理直接返回302。因为这个302会比目标服务器的正常返回早得多，所以用户浏览器会只认第一个302，而丢弃后到的正常返回。

如果先把第一个302丢弃，等待后续正常返回，则问题解决。

b) 终端拦截请求包，并拆包发送。

运营商一般判断是否劫持，通过判断是否HTTP请求。 一般只会检测TCP连接建立后的第一个数据包，如果其是一个完整的HTTP协议才会被标记；如果并非是一个完整的HTTP协议，由于无法得到足够多的劫持信息，所以并不会被标记为HTTP协议。

所以，只要把请求包切得足够细，就能躲过一部分劫持（如果运营商学习“墙”大力气做多包拦截就没辙了）。

5、当然，最终，根本解决办法是使用HTTPS，不过这个涉及到很多业务的修改，成本较高。如果劫持比例小，也许通过适当的补救做法会更好。

HTTP劫持和DNS劫持

（40）跨域

跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器施加的安全限制。
同源：域名，协议，端口均相同 即浏览器只能执行相同协议、相同域名、相同端口下的网站脚本，执行的时候如果网站的脚本不属于现在这个界面，就不会执行

HTTP请求响应中断原因
网断了，网络阻塞，请求超时，浏览器出问题，服务器出问题 如何检查 检查网络，检查本地…

（41） 一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？

linux socket使用16bit无符号整型表示端口号，最大到65535，不能改变，规定了是16bit二进制数，但是可以复用，即使用同一个端口号来进行通信

（42） 对称密码和非对称密码体系

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。
非对称加密指使用一对非对称密钥，即：公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。


由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性。但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

（43）什么是数字签名？

为了避免数据在传输过程中被替，比如有人修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

（44）什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。
数字证书是经过权威机构（CA）认证的公钥，通过查看数字证书，可以知道该证书是由那家权威机构签发的，证书使用人的信息，使用人的公钥。它有以下特点：
1、由专门的机构签发的数字证书才安全有效。
2、签发数字证书是收费的。
3、不会被冒充，安全可信。
4、数字证书有使用期限，过了使用期限，证书变为不可用。CA也可以在试用期内，对证书进行作废操作。

（45）客户端为什么信任第三方证书

第三方认证机构，是指具有可靠的执行认证制度的必要能力，并在认证过程中能够客观、公正、独立地从事认证活动的机构。即认证机构是独立于制造厂、销售商和使用者（消费者）的、具有独立的法人资格的第三方机构，故称认证为第三方认证认证机构。

（46）RSA加密算法，MD5原理（MD5不算加密算法）

MD5原理：MD5，全名Message Digest Algorithm 5，是一种摘要算法，通过内置的hash算法将信息摘要成为定长的十六进制字串

RSA加密算法：与DES不同，RSA算法中，每个通信主体都有两个钥匙，一个公钥一个私钥。就是有2把钥匙：使用publicKey可以对数据进行加密，使用私钥才能对数据进行解密。

（47） 单条记录高并发访问的优化

  1. 保证在实现功能的基础上，尽量减少对数据库的访问次数；

  2. 通过搜索参数，尽量减少对表的访问行数，最小化结果集，从而减轻网络负担；

  3. 能够分开的操作尽量分开处理，提高每次的响应速度；

  4. 在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；



（48） Ping的过程，分别用到了哪些协议

UDP ICMP ARP OSPF

具体过程是：

通过DNS协议，将ping后接的域名转换为ip地址。
DNS使用的传输层协议是UDP，传输层接收到请求，将其加上udp的头部，转发到IP层
IP层根据ICMP 协议进行封装，添加源IP和目标IP封装成为数据包，然后转到链路层
链路层接收到数据包，进行封装对应的mac地址，调用ARP协议，查询ARP缓存表，没有找到则广播出去，寻找对应IP的mac地址，这个过程用到了路由的协议OSPF。
ping是为了测试另一台主机是否可达，发送一份ICMP回显请求给目标主机，并等待 ICMP回显应答。（ICMP用于在ip主机、路由器间传递网络是否通畅、主机是否可达等控制信息）

ICMP是“Internet Control Message Ptotocol”的缩写。它是TCP/IP协议族的一个子协议，是一种面向无连接的协议，用于传输出错报告控制信息，用于在IP主机、路由器之间传递控制消息。

控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。在网络中经常会使用到ICMP协议。例如经常用于检查网络不通的ping命令，这个ping的过程实际上就是ICMP协议工作的过程。还有跟踪路由的trancert命令也是基于ICMP协议的。

分类：有ICMP差错报文和ICMP询问报文两种报文类型

CMP常用于探测网络联通性：
ping命令:通过发送网际控制报文‘回显应答’报文，来验证与另一台计算机的IP级连接。
tarcert命令:通过递增‘生存时间’构造网际控制报文‘回显应答’报文，达到路由追踪的目的。
pathping命令:一个将ping和tracert功能结合起来并用有所增强的网络诊断工具，可以反映出数据包从源主机到目的主机所经过的路径。网络延时及丢包率。
以上命令只是用于理想状况，实际状况是，很多公司和学校等都禁用或者拦截ICMP报文，特别路由追踪时，很难完整的探测出路由的路径。


（49）TCP/IP的分片粘包过程

粘包概念：
TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
粘包可能由发送方造成，也可能由接收方造成。
只有TCP有粘包现象，UDP永远不会粘包，粘包不一定会发生

UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。而UDP传输时，则没有。

下面对上面的图进行解释：
1.正常情况：如果Socket Client 发送的数据包，在Socket Server端也是一个一个完整接收的，那个就不会出现粘包和分包情况，数据正常读取。
2.粘包情况：Socket Client发送的数据包，在客户端发送和服务器接收的情况下都有可能发送，因为客户端发送的数据都是发送的一个缓冲buffer，然后由缓冲buffer最后刷到数据链路层的，那么就有可能把数据包2的一部分数据结合数据包1的全部被一起发送出去了，这样在服务器端就有可能出现这样的情况，导致读取的数据包包含了数据包2的一部分数据，这就产生粘包，当然也有可能把数据包1和数据包2全部读取出来。
3.分包情况：意思就是把数据包2或者数据包1都有可能被分开一部分发送出去，接着发另外的部分，在服务器端有可能一次读取操作只读到一个完整数据包的一部分。
4.在数据包发送的情况下，有可能后面的数据包分开成2个或者多个，但是最前面的部分包，黏住在前面的一个完整或者部分包的后面，也就是粘包和分包同时产生了。

发生TCP粘包或拆包有很多原因
1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

解决这个问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：
1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。


# （50） 有没有抓过TCP包，描述一下
# （51） 一个ip配置多个域名，靠什么识别？ 一个IP可以绑定无数个域名，这个没有限制。

IIS 5.0能很好地支持一个IP地址对应多个独立的域名，这可以通过两种方法来实现：
⑴ 设不同的TCP端口号：你需要分别将各个Web站点的“Web站点”选项中的“TCP端口”指向不同的端口号，再将“主目录”中的路径选不同的目录即可。调用格式如“http://www.abc:99”。
⑵ 设不同的主机头名：你需要分别将各个Web站点的“Web站点→高级→编辑”中的“主机头名”一项填入不同的域名，再将“主目录”中的路径选不同的目录即可。调用格式如“http://www.bbc”。

（52） 服务器攻击（DDos攻击）

分布式拒绝服务攻击(DDoS:Distributed Denial of Service)，强调是将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。大量恶意的流量去访问同一个服务器，导致服务器处理不过来，功能瘫痪。

随着网络技术发展，DDOS攻击也在不断进化，攻击成本越来越低，而攻击力度却成倍加大，使得DDOS更加难以防范。比如反射型DDoS攻击就是相对高阶的攻击方式。攻击者并不直接攻击目标服务IP，而是通过伪造被攻击者的IP向全球特殊的服务器发请求报文，这些特殊的服务器会将数倍于请求报文的数据包发送到那个被攻击的IP（目标服务IP）。

DDOS攻击让人望而生畏，它可以直接导致网站宕机、服务器瘫痪，对网站乃至企业造成严重损失。而且DDOS很难防范，可以说目前没有根治之法，只能尽量提升自身“抗压能力”来缓解攻击，比如购买高防服务。

（53）DNS的查找过程（应用层）

第一步：浏览器输入域名
浏览器会把输入的域名解析成对应的IP，其过程如下：
1.查找浏览器缓存：因为浏览器一般会缓存DNS记录一段时间，不同浏览器的时间可能不一样，一般2-30分钟不等，浏览器去查找这些缓存，如果有缓存，直接返回IP，否则下一步。
2.查找系统缓存：浏览器缓存中找不到IP之后，浏览器会进行系统调用（windows中是gethostbyname），查找本机的hosts文件，如果找到，直接返回IP，否则下一步。
3.查找路由器缓存：如果1,2步都查询无果，则需要借助网络，路由器一般都有自己的DNS缓存，将前面的请求发给路由器，查找ISP 服务商缓存 DNS的服务器，如果查找到IP则直接返回，没有的话继续查找。
4.递归查询：如果以上步骤还找不到，则ISP的DNS服务器就会进行递归查询，所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）
5.迭代查询：本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地域名服务器自己进行后续的查询。（而不是替代本地域名服务器进行后续查询）。
本例子中：根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns的IP地址。本地域名服务器向顶级域名服务器dns进行查询。顶级域名服务器dns告诉本地域名服务器，下一次应查询的权限域名服务器dns.csdn的IP地址。本地域名服务器向权限域名服务器dns.csdn进行查询。权限域名服务器dns.csdn告诉本地域名服务器，所查询的主机www.csdn的IP地址。本地域名服务器最后把结果告诉主机。

（54）谈谈你对域名缓存的了解？

为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。
由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。
不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。

（55）DNS为什么使用UDP协议、DNS什么时候使用TCP协议

dns有两个情况，一种是区域传输，一种是域名解析
1.区域传输时，一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息，传输协议是tcp。

2.域名解析时一般返回的内容都不超过512字节，首选的通讯协议是udp。使用udp传输，不用经过TCP三次握手，这样DNS服务器负载更低，响应更快

3.当域名解析的反馈报文的长度超过512字节时，将不能使用udp协议进行解析，此时必须使用tcp。通常传统的UDP报文一般不会大于512字节。
区域传输使用TCP协议的原因大概是：
1） 区域传输的数据量相比单次DNS查询的数据量要大得多
2） 区域传输对数据的可靠性和准确性相比普通的DNS查询要要高得多，因此使用TCP协议

（56）什么是静态资源、什么是动态资源？

直接把相应文件发送到客户端的文件都是静态资源。
如果不同的用户可以得到不同的回答，是动态资源，一般是指数据库资源。

静态资源和动态资源的概念
静态资源：一般客户端发送请求到web服务器，web服务器从内存在取到相应的文件， 返回给客户端，客户端解析并渲染显示出来。
动态资源：一般客户端请求的动态资源，先将请求交于web服务器，web服务器连接数据库，数据库处理数据之后，将内容交给web服务器，web服务器返回给客户端解析渲染处理。

静态资源和动态资源的区别
a. 静态资源一般都是设计好的html页面，而动态资源依靠设计好的程序来实现按照需求的动态响应；
b. 静态资源的交互性差，动态资源可以根据需求自由实现；
c. 在服务器的运行状态不同，静态资源不需要与数据库参于程序处理，动态可能需要多 个数据库的参与运算

（57）动态主机配置协议DHCP的过程

一、DHCP的作用
　　我们先来看一下什么是DHCP，DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)它可以为客户机自动分配IP地址、子网掩码以及缺省网关、DNS服务器的IP地址等TCP/IP参数，简单来说，就是在DHCP服务器上有一个数据库，存放着IP地址、网关、DNS等参数。当客户端请求使用时，服务器则负责将相应的参数分配给客户端。以避免客户端手动指定IP地址等。特别是在一些大规模的网络中。客户端数目较多，使用DHCP可以方便对这些机器进行管理，为客户机提供TCP/IP参数配置，如IP地址、网关地址和DNS服务器等，不仅效率高，而且不存在IP地址冲突的情况。现在的无线路由器默认都带有DHCP功能，也就是说一个无线路由器同时也是一个DHCP服务器。
二、DHCP的工作过程：
　　那么客户端是怎么从DHCP服务器(也就是我们的无线路由器或无线AP)上获得地址的呢?
三、DHCP工作过程
　　1.DHCP DISCOVER: 寻找服务器
　　当DHCP客户端第一次登录网络的时候或者是开机时，此计算机发现本机上没有任何IP地址设定，就会向网络广播去寻找DHCP服务器。该数据包的来源地址会为0.0.0.0，而目的地址则为255.255.255.255。
　　2. DHCP OFFER分配IP地址
　　当无线设备监听到客户端发出的寻找服务器的数据包后，它会从那些还没有分配出的IP地址里，选择最前面的的空闲IP，给客户端一个分配IP地址，但这里仅仅是分配，客户端还没有真正应用上。
　　3. DHCP REQUEST 请求使用
　　客户端收到无线设备发送回来的分配IP地址数据包，客户端会向网络发送一个ARP数据包，确认网络中没有其他机器使用该IP地址，如果已经有，则重复发送步骤1中的动作;如果没有，则接受该IP地址，并发送一个DHCP request数据包给DHCP服务器，请求使用此地址。
　　4. DHCP ACK IP地址分配确认
　　当无线设备接收到客户端的DHCP request数据包之后，会向客户端发出一个DHCP ACK回应，以确认IP地址的正式生效，也就结束了一个完整的DHCP工作过程。
　　当此过程完成之后，DHCP客户端再重新登录网络时，就不需要再发送DHCP discover发现信息了，而是直接发送包含前一次所分配的IP地址的DHCP request请求信息。当DHCP服务器收到这一信息后，它会尝试让DHCP客户机继续使用原来的IP地址，并回答一个DHCP ack确认信息。如果此IP地址已无法再分配给原来的DHCP客户机使用时，则DHCP服务器给DHCP客户机回答一个DHCP nack否认信息。当原来的DHCP客户机收到此DHCP nack否认信息后，它就必须重新发送DHCPdiscover发现信息来请求新的IP地址。
　　但DHCP服务器向DHCP客户机出租的IP地址一般都有一个租借期限，期满后DHCP服务器便会收回出租的IP地址。如果DHCP客户机要延长其IP租约，则必须更新其IP租约。DHCP客户机启动时和IP租约期限过一半时，DHCP客户机都会自动向DHCP服务器发送更新其IP租约的信息。

（58）什么是NAT (Network Address Translation, 网络地址转换)？

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换


（59）集线器、网桥、交换机、路由器

网线是物理层的硬件
集线器（Hub）是物理层的硬件，连接所有的线路，广播所有信息
网桥（Bridge）是数据链路层的硬件。网桥隔离两个端口，不同的端口形成单独的冲突域，减少网内冲突。网桥在不同或相同类型的 LAN 之间存储并转发数据帧，根据 MAC 头部来决定转发端口，显然是数据链路层的设备
交换机（Switch）是数据链路层的硬件，相当于多端口的网桥。交换机内部存储 MAC 表，只会将数据帧发送到指定的目的地址
路由器（Router）是网络层的硬件，根据 IP 地址进行寻址，不同子网间的数据传输隔离


（60）MSL、TTL、RTT 是什么？

MSL（Maximum segment lifetime）：报文最大生存时间。它是任何 TCP 报文在网络上存在的最长时间，超过这个时间报文将被丢弃。实际应用中常用的设置是 30 秒，1 分钟和 2 分钟。
应用场景：TCP 四次挥手时，需要在 TIME-WAIT 状态等待 2MSL 的时间，可以保证本次连接产生的所有报文段都从网络中消失。

TTL（Time to live）：IP 数据报在网络中可以存活的总跳数，称为“生存时间”，但并不是一个真正的时间。该域由源主机设置初始值，每经过一个路由器，跳数减 1，如果减至 0，则丢弃该数据包，同时发送 ICMP 报文通知源主机。取值范围 1-255，如果设置的 TTL 值小于传输过程中需要经过的路由器数量，则该数据包在传输中就会被丢弃。

RTT（Round trip time）：客户端到服务端往返所花时间。RTT 受网络传输拥塞的变化而变化，由 TCP 动态地估算。


（61）LAN、WAN、WLAN、VLAN和VPN的区别

一、局域网(Local Area Network，LAN)
是指在某一区域内由多台计算机互联成的计算机组。局域网是封闭型的可以实现文件管理、打印机共享、电子邮件等功能。
二、广域网 (Wide Area Network，WAN)
是一种跨越大的、地域性的计算机网络的集合。通常跨越省、市，甚至一个国家。
三、路由器的 WAN 口和 LAN 口
现在的宽带路由器实际上是路由 + 交换机的一体结构，我们可以把它当成是两台设备。
WAN：接外部 IP 地址用，通常指的是出口，转发来自内部 LAN 接口的 IP 数据包。
LAN：接内部 IP 地址用，LAN 内部是交换机。我们可以不连接 WAN 口，把路由器当做普通交换机来使用
四、无线局域网(Wireless LAN, WLAN)
WLAN 利用电磁波在空气中发送和接受数据，而无需线缆介质。传输速率达到 11Mbps，距离至 20km 以上。
WIFI 是实现无线组网的一种协议，WIFI 是 WLAN 的一个标准。WIFI 网络工作在 2.4G 或 5G 的频段。另外 3G/4G 也属于无线上网，但协议都不一样!

五、虚拟局域网(Virtual Local Area Network，VLAN)
是指网络中的站点不拘泥于所处的物理位置，根据需要划分不同的逻辑子网。
例如位于不同楼层的用户加入不同的虚拟局域网：1 楼划分为 192.168.1.0 网段，2 楼划分为 192.168.2.0 网段等。
六、虚拟专用网络(Virtual Private Network，VPN)
虚拟专用网络功能是：在公用网络上建立专用网络，进行加密通讯。VPN 网关通过对数据包的加密和数据包目标地址的转换实现远程访问。
企业网络中要远程访问，传统的方法是租用 DDN(数字数据网)专线或帧中继，导致高昂的费用。内网中架设一台 VPN 服务器，被广泛企业采用。
当我们联上美国的 VPN 服务器，所有数据传输都经过这台美国服务器，相当于你人在美国一样。
VPN由VPN服务器、VPN连接（internet公共网络）、协议隧道、VPN客户机组成。
工作原理

1、通常情况下，VPN网关采取双网卡结构，外网卡使用公网IP接入Internet。
2、网络一（假定为公网internet）的终端A访问网络二（假定为公司内网）的终端B，其发出的访问数据包的目标地址为终端B的内部IP地址。
3、网络一的VPN网关在接收到终端A发出的访问数据包时对其目标地址进行检查，如果目标地址属于网络二的地址，则将该数据包进行封装，封装的方式根据所采用的VPN技术不同而不同，同时VPN网关会构造一个新VPN数据包，并将封装后的原数据包作为VPN数据包的负载，VPN数据包的目标地址为网络二的VPN网关的外部地址。
4、网络一的VPN网关将VPN数据包发送到Internet，由于VPN数据包的目标地址是网络二的VPN网关的外部地址，所以该数据包将被Internet中的路由正确地发送到网络二的VPN网关。
5、网络二的VPN网关对接收到的数据包进行检查，如果发现该数据包是从网络一的VPN网关发出的，即可判定该数据包为VPN数据包，并对该数据包进行解包处理。解包的过程主要是先将VPN数据包的包头剥离，再将数据包反向处理还原成原始的数据包。
6、网络二的VPN网关将还原后的原始数据包发送至目标终端B，由于原始数据包的目标地址是终端B的IP，所以该数据包能够被正确地发送到终端B。在终端B看来，它收到的数据包就和从终端A直接发过来的一样。
7、从终端B返回终端A的数据包处理过程和上述过程一样，这样两个网络内的终端就可以相互通讯了。

在VPN网关对数据包进行处理时，有两个参数对于VPN通讯十分重要：原始数据包的目标地址（VPN目标地址）和远程VPN网关地址。根据VPN目标地址，VPN网关能够判断对哪些数据包进行VPN处理，对于不需要处理的数据包通常情况下可直接转发到上级路由；远程VPN网关地址则指定了处理后的VPN数据包发送的目标地址，即VPN隧道的另一端VPN网关地址。

由于网络通讯是双向的，在进行VPN通讯时，隧道两端的VPN网关都必须知道VPN目标地址和与此对应的远端VPN网关地址。

按VPN的协议分类VPN的隧道协议主要有三种：PPTP、L2TP和IPSec，其中PPTP和L2TP协议工作在OSI模型的第二层，又称为二层隧道协议；IPSec是第三层隧道协议。

（62）谈谈你对 ARQ 协议的理解？

自动重传请求 ARQ 协议
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。

（63）连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

（64）谈谈你对停止等待协议CSMA/CD的理解？

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到、确认丢失和确认迟到

设计题目：

在面对未知的流量暴增，可以预先怎么处理

高并发系统之限流特技
暴增原因：

不可预测流量（网站被恶意刷量；CDN回源抓取数据；合作业务平台调取平台数据等）
可预测流量（突然爆发的社会热点，营销活动的宣传；）

预备方案：
流量估算
降级方案
限流方案

如何限流，限流算法

计数器：计数器是一种比较简单的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限流。在一段时间内，进行计数，与阀值进行比较，到了时间临界点，将计数器清0。
问题：存在一个时间临界点的问题。

滑动窗口：滑动窗口的意思是说把固定时间片，进行划分，并且随着时间的流逝，进行移动，这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子，
将会进行计数判断阀值，因此格子的数量影响着滑动窗口算法的精度。

漏桶：虽然滑动窗口有效避免了时间临界点的问题，但是依然有时间片的概念，而漏桶算法在这方面比滑动窗口而言，更加先进。

有一个固定的桶，进水的速率是不确定的，但是出水的速率是恒定的，当水满的时候是会溢出的。

令牌桶：

生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。（有一点生产令牌，消费令牌的意味）

不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。

 令牌桶和漏桶对比：

令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；

漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；

令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；

漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；

令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；

两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是

什么是RPC协议？HTTP和RPC的区别

RPC是一种远程过程调用的协议，使用这种协议向另一台计算机上的程序请求服务，不需要了解底层网络技术的协议。

在 RPC 中，发出请求的程序是客户程序，而提供服务的程序是服务器。

HTTP是一种超文本传输协议。是WWW浏览器和WWW服务器之间的应用层通讯协议

HTTP和RPC的异同:
传输协议
RPC，可以基于TCP协议，也可以基于HTTP协议
HTTP，基于HTTP协议

传输效率
RPC，使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率
HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装一下是可以作为一个RPC来使用的，这时标准RPC框架更多的是服务治理

性能消耗，主要在于序列化和反序列化的耗时
RPC，可以基于thrift实现高效的二进制传输
HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡
RPC，基本都自带了负载均衡策略
HTTP，需要配置Nginx，HAProxy来实现

服务治理（下游服务新增，重启，下线时如何不影响上游调用者）
RPC，能做到自动通知，不影响上游
HTTP，需要事先通知，修改Nginx/HAProxy配置

网站出现504错误的解决方法

504错误
504 Gateway Time-out就字面意思，我们可以理解为网页请求超时，也就是浏览网站网页所发出的请求没有反应或者未响应，在网站程序层面来说，就是请求未能够执行相应的PHP-CGI程序，或者PHP-CGI程序未能做出相应的处理，又或者是CGI程序的响应处理结果未能够反馈到浏览器或者未能及时反馈到浏览器。
　　
　　 504 Gateway Time-out错误 多是存在于Nginx网站服务器环境下，多与nginx.conf与php-fpm.conf设置是否正确合理有关。504GatewayTime-out错误的解决方法就是根据网站服务器性能及网站流量等诸多因素整合考虑，正确合理的设置niginx.conf和php-fpm.conf配置。
　　
　　进行正确合理nginx.conf配置，我们需要先了解和清楚我们网站服务器的配置性能，包括CPU、内存等，并对网站服务器进行必要的性能测试（可参考：vps主机性能测试方法详解），从而准确的掌握网站服务器自身性能状况；
　　还有就是php-fpm.conf中max_children与request_terminate_timeout两个重要参数的设置。这两个参数的设置需要我们根据PHP程序情况及服务器带宽状况综合考虑并计算出合理准确的值，才能够避免 504 Gateway Time-out 或者其他CGI无响应错误的出现。通常情况下，般网站，可将request_terminate_timeou设置在900s左右，而max_children值根据服务器内存大小和CGI请求数目设置为合理的数值，般设置为800M左右。

网站出现502错误的解决方法

是指请求的php-fpm已经执行，但是由于某种原因而没有执行完毕，最终导致php-fpm进程终止。一般来说，与php-fpm.conf的设置有关，也与php的执行程序性能有关，网站的访问量大，而php-cgi的进程数偏少


输入 www.baidu ，怎么变成 https://www.baidu 的，怎么确定用HTTP还是HTTPS

一种是原始的302跳转，服务器把所有的HTTp流量跳转到HTTPS。但这样有一个漏洞，就是中间人可能在第一次访问站点的时候就劫持。
解决方法是引入HSTS机制，用户浏览器在访问站点的时候强制使用HTTPS。

什么是 HSTS?
简单来说支持 HSTS 的服务端，可以强制访问它的浏览器使用 HTTPS 协议。 这样就可以最大限度的减少 HTTP 协议的各种安全问题了。
HSTS 的实现也很简单，通过 HTTPS 协议访问你站点的时候，在相应头中加上这样一段信息：

Strict-Transport-Security “max-age=63072000; includeSubdomains;”

其实大家平时在使用浏览器的时候，一般是直接在地址栏里面输入域名，然后就访问了。 但大家应该知道，大多数浏览器在默认情况下会先用 HTTP 发起请求的。也就是说即便你的站点已经支持了 HTTPS，但如果不做任何处理的话，用户还是很难触及到。

而为什么我们平时访问很多网站的时候自动就跳转到 HTTPS 站点了呢，也是因为这些站点对这一点做了处理。 最原始的方法就是 302 跳转，服务端把所有的 HTTP 流量跳转到 HTTPS 上。 但这样做有一个明显的安全漏洞， 就是第一次访问站点的时候如果是 HTTP 就有可能被中间人劫持，很可能都没到 302 跳转的时候就被劫持了。

这也就是为什么要引入 HSTS 机制的原因了。 用户的浏览器一旦得到了 HSTS 的信息，下次再访问站点的时候客户端浏览器就会强制使用 HTTPS。 无论你在地址栏里输入什么，都会以 HTTPS 访问。 这样就避免了每次服务端跳转可能导致的潜在安全问题。

这样就解释了为什么我们使用主流浏览器输入网站域名的时候，都会自动跳转到 HTTPS 了。 因为我们访问的大多是主流的大网站，所以用户的感觉就是 HTTPS 自动发生了。但实际上并不是这样的。

发送窗口的大小，如何最大利用带宽，假设延迟100ms，发送端10Mb/s，接收端100Mb/s.

https://blog.csdn/bad_sheep/article/details/6158676

cookie 与 session

cookie和session的区别是什么
cookie数据存放在客户的浏览器上，session数据放在服务器上
(当你登录一个网站的时候，如果web服务器端使用的是session,那么所有的数据都保存在服务器上面，客户端每次请求服务器的时候会发送 当前会话的session_id，服务器根据当前session_id判断相应的用户数据标志，以确定用户是否登录，或具有某种权限，由于数据是存储在服务器 上面，所以你不能伪造，但是如果你能够获取某个登录用户的session_id，用特殊的浏览器伪造该用户的请求也是能够成功的，session_id是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性）
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session
设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)
两者最大的区别在于生存周期，一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)
PS：
①session很容易失效,用户体验很差
②虽然cookie不安全,但是可以加密
③cookie也分为永久和暂时存在的
④浏览器 有禁止cookie功能，但一般用户都不会设置
⑤cookie一定要设置失效时间,要不然浏览器关闭就消失了

注： Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效

udp如何实现可靠性传输？

https://blog.csdn/gettogetto/article/details/76736365
UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

     传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

     实现确认机制、重传机制、窗口确认机制。

     如果你不利用Linux协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：

     发送：包的分片、包确认、包的重发

     接收：包的调序、包的序号确认

     目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，谈谈自己的个人简单粗暴的设计。

1、添加seq/ack机制，确保数据发送到对端。
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制。
4、发送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。
5、时间到后，定时任务检查是否需要重传数据

微信扫码登录网页实现原理

扫码登录操作过程

  • 浏览器输入：https://wx.qq/?lang=zh_CN
  • 手机登录微信，利用“扫一扫”功能扫描网页上的二维码
  • 手机扫描成功后，提示“登录网页版微信”；网页上显示“成功扫描 请在手机点击确认以登录”
  • 手机端点击“登录网页版微信”，网页跳转到用户的微信操作界面
    整个扫码登录的操作过程还是挺简单的，而且交互地实时性比较好，如果网络不是非常阻塞，整个过程还是非常快的。

扫码登录原理

1.每次打开微信网页版的时候，都会生成一个含有唯一uid的二维码，而且每次刷新后都会改变。这样可以保证一个uid只可以绑定一个账号和密码，确定登录用户的唯一性。可以通过手机上的UC浏览器提供的扫码功能查看二维码里面的信息，但并不会自动打开该地址。

2.除了返回唯一的uid，实际上打开这个页面的时候，浏览器跟服务器还创建了一个长连接，请求uid的扫描记录。如果没有，在特定时长后（目前是27秒左右）会接到状态码408（请求超时），表示应该继续下一次请求；如果接到状态码201（服务器创建新资源成功），表示客户端扫描了该二维码。

3.当用户使用登录后的微信扫描二维码的时候，会将uid和手机微信产生的token进行绑定，并上传到服务器。这个时候，浏览器通过长轮询查询到uid扫描记录，立即得到201响应码，然后通知服务器，客户端由此也进入一个新的页面（就是那个要你点确认的按钮）。在客户端点击确认后，获得服务器授信的令牌，进行随后的信息交互过程。

结语
总的来说，微信扫码登录核心过程应该是这样的：浏览器获得一个唯一的、临时的uid，通过长连接等待客户端扫描带有此uid的二维码后，从长连接中获得客户端上报给服务器的帐号信息进行展示。并在客户端点击确认后，获得服务器授信的令牌，进行随后的信息交互过程。 在超时、网络断开、其他设备上登录后，此前获得的令牌或丢失、或失效，对授权过程形成有效的安全防护。

布隆过滤器的原理

本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。

相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。

https://zhuanlan.zhihu/p/43263751

本文标签： 计算机网络 最终版

版权声明：本文标题：计算机网络【最终版】 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1725920744h892963.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。