七层网络协议
物理层
物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。
中继器(Repeater,也叫放大器)和集线器是物理层重要的两个设备。
数据链路层
使用帧进行数据传输,帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等)。
交换机内部的CPU会在每个端口成功连接时,通过ARP协议学习它的MAC地址,保存成一张 ARP表。在今后的通讯中,发往该MAC地址的数据包将仅送往其对应的端口,而不是所有的端口。因此,交换机可用于划分数据链路层广播,即冲突域;但它不 能划分网络层广播,即广播域。
网络层
网络层的目的是实现两个主机系统之间的数据透明传送,具体功能包括寻址和路由选择、连接的建立、保持和终止等。它提供的服务使传输层不需要了解网络中的数据传输和交换技术。如果您想用尽量少的词来记住网络层,那就是“路径选择、路由及逻辑寻址”。
IP协议(Internet Protocol,因特网互联协议)
- 网络地址:IP地址由网络号(包括子网号)和主机号组成,网络地址的主机号为全0,网络地址代表着整个网络。
- 广播地址:广播地址与网络地址的主机号正好相反,广播地址中,主机号为全1。当向某个网络的广播地址发送消息时,该网络内的所有主机都能收到该广播消息。
- 组播地址,D 类地址就是组播地址
IP 地址根据网络地址不同,可以分为 5 类:
- A类地址以0开头,第一个字节作为网络号,地址范围为:0.0.0.0~127.255.255.255;(modified @2016.05.31)
- B类地址以10开头,前两个字节作为网络号,地址范围是:128.0.0.0~191.255.255.255;
- C类地址以110开头,前三个字节作为网络号,地址范围是:192.0.0.0~223.255.255.255。
- D类地址以1110开头,地址范围是224.0.0.0~239.255.255.255,D类地址作为组播地址(一对多的通信);
- E类地址以1111开头,地址范围是240.0.0.0~255.255.255.255,E类地址为保留地址,供以后使用。
注:只有A,B,C有网络号和主机号之分,D类地址和E类地址没有划分网络号和主机号。
IP 数据包
ICMP协议(Internet Control Message Protocol,因特网控制报文协议)
ARP协议(Address Resolution Protocol,地址解析协议)可看成是跨网络层和链路层的协议;
路由器
传输层
为应用进程之间提供端到端的逻辑通信
Cookie 与 Session
Cookie 是服务器发送到用户浏览器并保存到本地的一小块数据,在浏览器下一次向同一个服务器发起请求的时候带上。
主要用于:
- 会话状态管理(登陆状态,购物车等)
- 个性化管理(用户自定义设置,主题)
- 浏览器行为跟踪
Session 代表服务器与客户端一次会话的过程,在服务器端进行存储。
区别:
- 作用范围不同,Cookie 在客户端,Session 在服务器
- 存取方式不同,Cookie 只能保存 ASCII,Session 可以任意数据类型
- 有效期不同,Cookie 可以设置长时间;Seesion 失效时间较短
- 可存储大小不同,单个 Cookie 保存的数据不超过 4K,Session 不只
联系:
用户第一次请求服务器的时候,服务器会创建对应的 Session,返回给客户端时,会将 Session 的 SessionID 返回给浏览器,浏览器将 SessionID 保存到 Cookie 中,并记录 SessionID 所属域名。
第二次请求时,浏览器会判断该域名下面是否有对应 Cookie,有的话会将 Cookie 发送给服务端,服务端获取到 Cookie 中的 SessionID 之后就可以认为这个用户之前登陆过。
SessionID 是 Cookie 和 Session 之间的桥梁。
若浏览器禁止了 Cookie,服务端就不能根据 Cookie 中的 SessionID 判断用户是否登陆,可以使用以下方式解决:
- 请求携带 SessionID 参数
- Token 机制,用户登陆之后返回一个 token 给客户端,客户端请求携带 token
分布式 Session:
一般来说,后端服务由多台服务器提供服务,如果用户在 A 服务器中登陆了,若 B 服务器中没有这个用户的 Session 就会出现问题,所以需要对 Session 进行管理。
- Nginx 的 ip_hash 策略,根据请求 IP 的 hash 值分配到指定服务器,这样就避免了访问不同服务器的情况
- Session 复制,每台服务器都保存同样的 Session
共享 Session,将 Session 放到缓存中间件中统一管理。
Apache HttpClient 超时时间
HttpClient 有 3 个超时时间设置,通过配置 RequestConfig 即可配置请求的超时时间,各个参数的作用如下:
connectTimeout:请求连接超时时间,超时会抛出 org.apache.http.conn.ConnectTimeoutException: Connect to 127.0.0.1:8083 [/127.0.0.1] failed: connect timed out异常。例如请求本地不存在的一个服务:http://127.0.0.1:8083
- socketTimeout:接收包的超时时间。服务端与客户端传输数据包之间的时间间隔,超过这个间隔将抛出 java.net.SocketTimeoutException: Read timed out
- connectionRequestTimeout:在使用线程池场景下,从连接池获取到连接的超时时间,时间超出将抛出 org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool ,线程池默认最大的连接数是 20。
PoolingHttpClientConnectionManager 作为连接池
- maxTotal:最大连接数
- defaultMaxPerRoute:每个路由最大连接数
代理
正向代理:客户端通过代理服务器访问受限的服务器,此时代理服务器作为客户端的代理,向服务器发起请求。
作用:
- 突破访问限制,通过代理方式访问被封的网站
- 隐藏客户端真实 IP
反向代理:代理服务器接收客户端请求,分发到内部服务器,响应内部服务器的结果给客户端
与正向代理不同的是,此时代理服务器是作为内部服务器的代理,客户端不知道真正调用的哪个服务器。
作用:
- 负载均衡,将请求分散到内部的各个服务器中
保证内部服务器安全,客户端只知道代理服务器的地址,不知道内部服务器的地址
联系
都需要代理服务器进行访问
- 都能够提供安全保障
-
区别
正向代理其实是客户端的代理,反向代理则是服务器的代理。
- 正向代理中,服务器并不知道真正的客户端到底是谁;反向代理中,客户端也不知道真正的服务器是谁。
- 应用场景不同:正向代理主要是用来解决访问限制问题;而反向代理则是提供负载均衡、安全防护等作用。
TCP
TCP协议(Transmission Control Protocol,传输控制协议)
- TCP 是面向连接的。(就好像打电话一样,通话前需要先拨号建立连接,通话结束后要挂机释放连接); 每一条 TCP 连接只能有两个端点,每一条TCP连接只能是点对点的(一对一);
- TCP 提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复、并且按序到达;
- TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存,用来临时存放双方通信的数据;
面向字节流。TCP 中的“流”(Stream)指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
报文格式
原端口号:2 byte
- 目的端口号: 2 byte
- 序号 :4 byte,用来确认发送的数据字节流序号,序号达到 2^32 - 1后又从 0 开始。
- 确认序号:4 byte,发送确认的一端期望收到的下一个序号,在确认标志位 ACK = 1 时有效
- 数据偏移:4 bit
报文段的数据距离起始处有多远,单位为 32 bit 字,又称 首部长度。
由于只有 4 bit,故最大值表示 15,15*32bit/8 = 60 byte,所以 TCP 首部长度最大可为 60 byte,由于固定首部的存在,首部偏移最小为 20 byte,所以选项长度不能超过 40 byte。 - 保留:6 bit 也有说 3 bit 4 bit,主要是标志位的不同导致,先不纠结。
- 标志位
- NS-ECN-nonce,标明阻塞即将发生
- CWR,Congestion Window Reduced
- ECE,ECN-Echo 有两种意思,取决于 SYN 标志的值
- URG 紧急,告知系统需要尽快发送,而不是排队
- ACK 确认,ACK = 1 时,上面的确认序号有效。TCP 规定连接建立后 ACK 必须为 1
- PSH 推送,把报文推送给另一方
- RST 复位,TCP 连接出现错误,需要重新连接。也可以用于拒绝一个非法报文或者拒绝打开连接
- SYN 同步,用于建立连接时同步序号
- FIN 终止,释放连接
- 窗口大小: 2 byte,从确认号开始,本报文发送方可以接收的字节数,用于流量控制;2 byte 能表示的最大正整数为 65535,也就是窗口最大值为 65535
- 校验和:2 byte,检验和覆盖整个 TCP 报文段;强制字段,由发送端存储,接收端校验
- 紧急指针:2 byte,紧急数据的最后一个字节的序号,指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据) ,当 Urgent 标志置 1 时,紧急指针生效
任选字段 0~40 byte:包括 选项类型,选项总长度,选项内容
滑动窗口
Sent and Acknowledged:这些数据表示已经发送成功并已经被确认的数据,比如图中的前31个bytes,这些数据其实的位置是在窗口之外了,因为窗口内顺序最低的被确认之后,要移除窗口,实际上是窗口进行合拢,同时打开接收新的带发送的数据
- Send But Not Yet Acknowledged:这部分数据称为发送但没有被确认,数据被发送出去,没有收到接收端的ACK,认为并没有完成发送,这个属于窗口内的数据。
- Not Sent,Recipient Ready to Receive:这部分是尽快发送的数据,这部分数据已经被加载到缓存中,也就是窗口中了,等待发送,其实这个窗口是完全有接收方告知的,接收方告知还是能够接受这些包,所以发送方需要尽快的发送这些包
- Not Sent,Recipient Not Ready to Receive: 这些数据属于未发送,同时接收端也不允许发送的,因为这些数据已经超出了发送端所接收的范围
拥塞控制
- 慢启动
在连接刚建立时接收窗口以指数方式增加,直到达到慢启动的阀值,或者是遇到丢包,开始进入拥塞回避阶段。
- 拥塞避免
在此阶段会使用 AIMD(Additive Increase Multiplicative Decrease)方式调整窗口大小,通过线性增加和指数衰减,逐渐逼近和收敛到一个理想值,从而达到充分利用带宽但又不引起拥塞的状态。
- 快重传
发送方如果收到连续3次重复的ACK确认,就认为出现了丢包,而不需要等到重传计时器超时。这样可以更早的检测到丢包,提高算法效率。
- 快恢复
检测到丢包后,直接进入拥塞回避阶段,将窗口大小调整为原来的一半,避免了慢启动的开销。
超时重传
- 自动重传 ARQ
只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重转时间应比数据在分组传输的平均往返时间更长一些 连续 ARQ
发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。三次握手与四次挥手
为什么要三次握手?两个目的,信息对等与防止超时。
SYN 泛洪攻击
利用 3 次握手特性,第一次请求连接之后不再响应,服务器处于半连接状态,服务器会重发 ACK 给攻击者,导致其它正常连接不能进行。
处理办法:
- 增加操作系统允许的最大半开连接数
- 降低 SYN timeout 时间,使得主机能够尽快释放半连接
- SYN Cookie,当 SYN 队列满时,服务器会适当返回 SYN+ACK 响应,但会丢弃 SYN 队列中的条目。如果服务器后续收到客户端的 ACK,那么能够重新组装数据流到队列中。
- TIME_WAIT 作用
被动关闭的一方能够顺利进入 CLOSED 状态。若主动关闭的一方 A 发送的 ACK 超时了,B 会认为 A 没有收到前面的 FIN+ ACK 请求,会再请求一次。
占用即将关闭的端口,防止已经失效的连接的请求数据包与正常的请求数据包混淆。
- 尽量处理 TIME_WAIT 过多的办法
查看 TCP 连接数:
netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
编辑内核文件 /etc/sysctl.conf,加入以下内容,然后执行 /sbin/sysctl -p 让参数生效。简单来说,就是打开系统的 TIMEWAIT 重用和快速回收。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间
如果以上配置调优后性能还不理想,可继续修改一下配置: vi /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 1200
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000
#表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000
#表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。
默认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于 Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。
TCP 粘包
现象: 发送方发送的多个数据包,到接收方缓冲区收尾相连,粘成一个包,被接收
原因: TCP 协议默认使用 Nagle 算法可能会把多个数据包一次发送到接收方。应用程读取缓存中的数据包的速度小于接收数据包的速度,缓存中的多个数据包会被应用程序当成一个包一次读取。
处理方式:
- 发送方使用 TCP_NODELAY 选项来关闭 Nagle 算法
- 数据包增加开始符和结束,应用程序读取、区分数据包
- 在数据包的头部定义整个数据包的长度,应用程序先读取数据包的长度,然后读取整个长度的包字节数据,保证读取的是单个包且完整
TCP对应的协议
FTP:定义了文件传输协议,使用21端口。
Telnet:一种用于远程登陆的端口,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务。
SMTP:邮件传送协议,用于发送邮件。服务器开放的是25号端口。
POP3:它是和SMTP对应,POP3用于接收邮件。POP3协议所用的是110端口。
HTTP:是从Web服务器传输超文本到本地浏览器的传送协议,端口默认80。UDP
无连接;尽最大努力交付,不需要维持复杂的链接状态;
面向报文
没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如 直播,实时视频会议等);
支持一对一、一对多、多对一和多对多的交互通信;
首部开销小,只有 8 个字节,比 TCP 的 20 个字节的首部要短。
报文格式
- 源端口号和目的端口号与 TCP 相同
- UDP 长度: 首部+ 数据的长度
- 校验和:伪头部,头部,data 三部分校验和
伪头部包括源 IP 地址、目的 IP 地址、IP 分组的协议字段、TCP 或 UDP 数据报的总长度等共12字节,它只是一个临时的结构,既不向上传递也不向下传递,仅仅是为了保证校验字段的正确性。
UDP 可靠传输
通信领域的 时延,成本,质量,3 者不可兼得。TCP 通过增大时延和传输成本保证通信的质量,UDP 通过牺牲质量来保证时延和通信的成本。
- 重传
- 定时重传,T1 时刻一个 RTO 之后还没收到 ACK 消息。ACK 发送途中丢失,ACK 在途但是时间超过一个 RTO;重点在于 RTO 的计算上,对延迟敏感但是流量成本要求不高,就把 RTO 设置小一点
- 请求重传,接收端发送 ACK 时候携带自己丢失信息的反馈,发送端根据反馈进行重传
- 重传会提升质量,但是会带来延时和带宽占用增加,设计窗口拥塞机制避免并发带宽占用过高
可靠的 UDP 协议:
- UDT(UDP-based Data Transfer Protocol)
- KCP,很简单的ARQ的实现,包括选择重传和快重传等机制,对上层提供一个可靠的字节流
- QUIC,Google实现的一种可靠UDP传输协议,并且已经被选择作为HTTP/3的基础
- uTP
- FASP(Aspera)
SCTP(Stream Control Transmission Protocol,流控制传输协议)
UDP 对应的协议
DNS:用于域名解析服务,将域名地址转换为IP地址。DNS用的是53号端口。
- SNMP:简单网络管理协议,使用161号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。
- TFTP(Trival File TransferProtocal),简单文件传输协议,该协议在熟知端口69上使用UDP服务。
为什么 TCP 叫数据流模式?
所谓的“流模式”,是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的,比如你通过 TCP连接给另一端发送数据,你只调用了一次 write,发送了100个字节,但是对方可以分10次收完,每次10个字节;你也可以调用10次write,每次10个字节,但是对方可以一次就收完。
原因:这是因为TCP是面向连接的,一个 socket 中收到的数据都是由同一台主机发出,且有序地到达,所以每次读取多少数据都可以。
所谓的“数据报模式”,是指UDP发送端调用了几次 write,接收端必须用相同次数的 read 读完。
UDP是基于报文的,在接收的时候,每次最多只能读取一个报文,报文和报文是不会合并的,如果缓冲区小于报文长度,则多出的部分会被丢弃。
原因:这是因为UDP是无连接的,只要知道接收端的 IP 和端口,任何主机都可以向接收端发送数据。 这时候,如果一次能读取超过一个报文的数据, 则会乱套。
HTTP、HTTPS
SSL(Secure Sockets Layer):互联网工程组 IETF 在 1999 年把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,版本号从 1.0 重新算起,所以 TLS1.0 实际上就是 SSLv3.1。
数字证书
证书的详细信息包含:版本号、序列号、签名算法、签名哈希算法、颁发者、有效期从、到、使用者、公钥、公钥参数、增强型密钥用法、使用者密钥标识符、授权信息访问、使用者可选名称、证书策略、CRL 分发点、SCT 列表、密钥用法、基本约束、指纹。
- 指纹:由 CA 机构对证书内容采用指纹算法,得到一个 hash 值,用于保证证书的完整性。若证书的信息若被修改,指纹内容也会发生变化。
验证证书合法性:服务端用私钥对指纹进行加密生成数字签名;客户端得到证书之后,通过对数字签名进行解密,得到指纹和证书内容,将证书内容进行散列得到的指纹与解密得到的指纹进行比对,即可验证证书是否被篡改。
HTTPS 加密过程
1.浏览器将自己支持的一套加密规则发送给网站。
- 2.网站从中选出一组加密算法与 HASH 算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。
- 3.获得网站证书之后浏览器要做以下工作:
- a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。
- b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
- c) 使用约定好的 HASH 计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。
- 4.网站接收浏览器发来的数据之后要做以下的操作:
- a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
- b) 使用密码加密一段握手消息,发送给浏览器。
- 5.浏览器解密并计算握手消息的 HASH,如果与服务端发来的 HASH 一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
HTTP 1.0 1.1 2.0 对比
HTTP/1.0
浏览器与服务器只保持短暂的连接,每次请求都需要重新建立 TCP 连接,连接无法复用。
缺点:队头阻塞(head of line blocking),即前面阻塞的请求会影响后面的请求。
HTTP/1.1
持久连接:TCP 连接默认不关闭,多个请求复用,header 里面的 connection : Keep-Alive
管道机制:同一个 TCP 连接可以同时发送多个请求,但是也有限制
引入更多的缓存策略:Cache-Control、Etag/If-None-Match 等
范围请求:增加 header 增加 range 标记,返回码是 206(Partial Content)时可选择继续请求
Header 增加 Host:将请求发往同一服务器上面不同网站,虚拟主机的应用
新增请求方式:PUT,DELETE,OPTIONS,TRACE,CONNECT
缺点: 队头阻塞,服务器只能按次序处理请求
HTTP 2.0
以 Google 2005 年发布的 SPDY 为基础,只基于 HTTPS 环境。
- 多路复用
HTTP/1.1 协议中的客户端同一时间,同一域名请求有数量限制;HTTP/2 把通信单位缩小为帧,在同一个 TCP 连接上面双向交换消息。每个 request 都有 id 值对应
- 二进制分帧
在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层
在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面
单连接 多资源的方式,基于 TCP 慢启动的特性,共用同一个连接可以有效使用 TCP 连接,吞吐量更大
- 首部压缩(Header Compression)
HTTP/1.1并不支持 HTTP 首部压缩,为此 SPDY 和 HTTP/2 应运而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度
- 服务端推送
在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应
http 报文格式
- 请求行
- 请求方法:GET POST 等
- URL
- 协议版本
- 请求头部:多个 key-value 值组成
- User-Agent:产生请求的浏览器类型
- Accept:客户端可识别的内容类型列表
- Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机
- 空行:将请求头部和请求数据分隔
- 请求数据:GET 方法没有携带数据,POST 会带一个 body
- 状态行
- 协议版本:HTTP-Version 服务器HTTP协议的版本
- 状态码:Status-Code 响应状态代码
- 状态值:Reason-Phrase表示状态代码的文本描述
- 响应头
- 空行
-
与 WebSocket 的联系与区别
在 WebSocket 出来之前,HTTP 协议是一个 请求-响应 的模式,如果需要实时与服务器进行通信,使用的是 js 脚本进行轮询,但是这样效率太慢。
WebSocket 是 HTML5 规范提出的协议,支持页面使用 Web Socket 协议与远程主机进行全双工通信,能够很好的节省服务器资源与带宽。
使用 ws:// wss:// 分别表示 WebSocket 和 安全的 WebSocket 连接。
几乎所有的实时应用程序都是用 WebSocket
相同点: 都是基于 TCP,可靠传输
- 都是应用层协议
差异:
- WebSocket 是双向通信协议,可以双向发送或接收信息。HTTP 是单向的
- WebSocket 需要浏览器与服务器握手建立连接(建立连接通过 HTTP,发送数据不需要),并且服务器可以主动向浏览器发送数据,可以不带有 head 部分信息。而 HTTP 是浏览器发起向服务器的连接,服务器预先不知道。
- WebSocket 建立连接之后不会断开,除非其中一方主动关闭。
DNS
DNS 全称 Domain Name System,域名系统,他能够将人类可读的域名转换为机器可读的 IP 地址,上述转换过程就是域名解析。
浏览器输入:www.baidu.com
- 检查浏览器缓存、Host 文件映射关系
- 请求本地 DNS 服务器(LDNS),查看是否有缓存;若没有缓存则请求 13 台根域名服务器(Root Server)
- 根域名服务器将返回主域名服务器(gTLD Server,国际顶尖域名服务器,如 .com .cn)的地址
- 本地域名服务器(LDNS)通过迭代的方式请求主域名服务器,主域名服务器返回域名对应的域名服务器(Name Server)
- Name Server 返回域名对应的 IP 地址
- 将返回的 IP 地址进行缓存,并返回客户端
- Cookie Session
- 数字证书 非对称加密