投稿
  1. 首页
  2. java

Java面试必背八股文[11]：计算机网络

code • 2022-5-6 • java • 阅读 352

Java面试必背八股文[11]：计算机网络,第1张

OSI与TCP/IP各层的结构？

答:OSI分层 （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP分层（4层）：网络接口层、 网际层、运输层、 应用层。

五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。

每一层的作用如下：

物理层：通过媒介传输比特,确定机械及电气规范（比特Bit）

数据链路层：将比特组装成帧和点到点的传递（帧Frame）

网络层：负责数据包从源到宿的传递和网际互连（包PackeT）

传输层：提供端到端的可靠报文传递和错误恢复（段Segment）

会话层：建立、管理和终止会话（会话协议数据单元SPDU）

表示层：处理两个通信系统中信息交换的表示方式，对数据进行翻译、加密和压缩（表示协议数据单元PPDU）

应用层：允许访问OSI环境的手段（应用协议数据单元APDU）

每一层的协议如下：

物理层：CLOCK、IEEE802.2 （中继器，集线器）

数据链路：PPP、FR、HDLC、VLAN、MAC （网桥，交换机）

网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）

传输层：TCP、UDP、SPX

会话层：NFS、SQL、NETBIOS、RPC

表示层：JPEG、MPEG、ASII

应用层：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

TCP与UDP 协议的区别？
传输控制协议（TCP）用户数据报协议（UDP）
TCP是一种面向连接的数据传输协议UDP是面向数据报的数据传输协议
保证数据可以安全到达接收器无法保证数据可以安全到达接收器
使用数据确认和流控制来执行深入的错误检查使用校验和来搜索传输中的基本错误
数据排序由TCP处理数据排序需要由应用程序处理
TCP比UDP慢，并且是重量级协议UDP比TCP更快，是一种轻量级协议
HTTP，SMPT，FTP和Telnet使用TCP进行数据交换DNS，DHCP，TFTP，VoIP和RIP利用UDP进行数据交换
TCP不允许广播UDP允许广播
标头长度可以在20到80个字节之间变化标头长度固定为8个字节
TCP 报文格式

TCP三次握手与四次挥手？ 三次握手过程理解

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

客户端–发送带有 SYN 标志的数据包–一次握手–服务端
服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

四次挥手过程理解

1）**客户端进程发出连接释放报文，并且停止发送数据。**释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）**服务器收到连接释放报文，发出确认报文，**ACK=1，ack=u+1，并且带上自己的序列号seq=v，**此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。**TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，**客户端就进入了 TIME-WAIT（时间等待）状态。**注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）**服务器只要收到了客户端发出的确认，立即进入CLOSED状态。**同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。

但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了，但是还能接收数据；但未必己方所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示同意现在关闭连接，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

**第一，为了保证A发送的最后一个ACK报文能够到达B。**这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
**第二，避免上一次TCP连接的数据包影响到下一次的TCP连接。**A在发送完ACK报文段后，再经过2MSL(Maximum Segment Lifetime)时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

【问题3】为什么不能用两次握手进行连接？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

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

TCP 协议如何保证可靠传输？
  1. 应用数据被分割成 TCP 认为最适合发送的数据块。
  2. 确认应答+序列号：TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
  3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，⽬的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
  4. TCP 的接收端会丢弃重复的数据。
  5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
  6. 拥塞控制： 当网络拥塞时，减少数据的发送。
  7. ARQ协议（自动重传请求 Automatic Repeat-reQuest，ARQ）： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
  8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待⽬的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
流量控制

什么是流量控制？

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

如何实现流量控制？

由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

流量控制引发的死锁？怎么避免死锁的发生？

当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

拥塞控制

拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；

常用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。

拥塞控制的算法

（一）慢开始算法：

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

（二）拥塞避免算法：

拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

（三）快重传算法：

快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

（四）快恢复算法：

与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

  1. 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh 减半。这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。
  2. 由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连有好几个报文段连续到达接收方，也就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口 cwnd 现在不设置为 1），而是把 cwnd 值设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

什么是TCP粘包问题？

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

造成TCP粘包的原因

（1）发送方原因

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：

  • 只有上一个分组得到确认，才会发送下一个分组
  • 收集多个小分组，在一个确认到来时一起发送

Nagle 算法造成了发送方可能会出现粘包问题

（2）接收方原因

TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

如何处理粘包现象？

（1）发送方

对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方

接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

（2）应用层

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

  1. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
  2. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。
TCP半关闭,半连接,半打开

半关闭：
当TCP链接中A向B发送 FIN 请求关闭，另一端B回应ACK之后，并没有立即发送 FIN 给A，A方处于半连接状态（半开关），此时A可以接收B发送的数据，但是A已经不能再向B发送数据。

半连接：
发生在TCP三次握手中，如果A向B发起链接，B也按照正常情况响应了，但是A不进行三次握手，这就是半连接。
半连接攻击：半连接，会造成B分配的内存资源就一直这么耗着，直到资源耗尽。（SYN攻击）

半打开：
如果一方关闭或者异常关闭（断电，断网），而另一方并不知情，这样的链接称之为半打开。处于半打开的连接，如果双方不进行数据通信，是发现不了问题的，只有在通信是才真正的察觉到这个连接已经处于半打开状态，如果双方不传输数据的话，仍处于连接状态的一方就不会检测另外一方已经出现异常。

解决方法：

如何解决半打开问题，引入心跳机制就可以察觉半打开。

如果需要发数据的话，这边收到之后 其实发现这个连接并不存在了，就会回复RST包告知，这个时候就需要重新建立连接了。

SYN泛洪攻击：

SYN攻击利用的是TCP的三次握手机制，攻击端利用伪造的 IP 地址向被攻击端发出请求，而被攻击端发出的响应报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。

SYN泛洪攻击的防范措施：

对于SYN泛洪攻击的防范，优化主机系统设置是常用的手段。如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

Socket 通信的基本步骤

根据socket通信基本流程图，总结通信的基本步骤：
服务器端：
第一步：创建一个用于监听连接的Socket对像；
第二步：用指定的端口号和服务器的ip建立一个EndPoint对像；
第三步：用socket对像的Bind()方法绑定EndPoint；
第四步：用socket对像的Listen()方法开始监听；
第五步：接收到客户端的连接，用socket对像的Accept()方法创建一个新的用于和客户端进行通信的socket对像;
第六步：通信结束后一定记得关闭socket;
客户端：
第一步：建立一个Socket对像；
第二步：用指定的端口号和服务器的ip建立一个EndPoint对像；
第三步：用socket对像的Connect()方法以上面建立的EndPoint对像做为参数，向服务器发出连接请求；
第四步：如果连接成功，就用socket对像的Send()方法向服务器发送信息；
第五步：用socket对像的Receive()方法接受服务器发来的信息 ;
第六步：通信结束后一定记得关闭socket；

服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。

在浏览器中输入url地址 ->> 显示页面的过程
  1. DNS解析
  2. TCP连接
  3. 发送HTTP请求
  4. 服务器处理请求并返回HTTP报文
  5. 浏览器解析渲染页面
  6. 连接结束

1、客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.181.27.48，然后通过TCP进行封装数据包，输入到网络层。

2、在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。

3、客户端的网络层不用关心应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，就是通过查找路由表决定通过那个路径到达服务器。

4、客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。

什么是DNS?DNS端口号是多少?

DNS全称是domain name service即:域名解析服务。DNS端口号是 53。

DNS是互联网中的一项核心服务，是用于实现域名和IP地址相互映射的一个分布式数据库，它将简单明了的域名翻译成可由计算机识别的IP地址，使用户可以更快速便捷地访问互联。

什么是DNS服务器?

DNS服务器就是域名服务器,即提供域名解析的服务器。

互联网连通的是全球资源，单一的域名服务器不足以支撑全部的地址转换 *** 作，因此全球有多套域名服务器相互配合使用。早在1983年互联网就开始采用层次树状结构的命名方法，并使用分布式的域名系统进行解析 *** 作。这样既提升了域名解析的效率，同时也保障了域名解析的稳定性，如果系统中单个域名服务器出现故障，不会对整个DNS系统的正常运行造成太大影响。

DNS域名解析原理？

DNS的工作原理及过程分下面几个步骤：

（1）查看浏览器缓存

当用户通过浏览器访问某域名时，浏览器首先会在自己的缓存中查找是否有该域名对应的 IP 地址（若曾经访问过该域名且没有清空缓存便存在）。

（2）查看系统缓存

当浏览器缓存中无域名对应 IP 则会自动检查用户计算机系统 Hosts 文件 DNS 缓存是否有该域名对应 IP。

（3）查看路由器缓存

当浏览器及系统缓存中均无域名对应 IP 则进入路由器缓存中检查，以上三步均为客服端的 DNS 缓存。

（4）查看ISP DNS 缓存

当在用户客服端查找不到域名对应 IP 地址，则将进入 ISP DNS 缓存中进行查询。比如你用的是电信的网络，则会进入电信的 DNS 缓存服务器中进行查找。

（5）询问根域名服务器

当以上均未完成，则进入根服务器进行查询。全球仅有 13 台根域名服务器，1 个主根域名服务器，其余 12 为辅根域名服务器。根域名收到请求后会查看区域文件记录，若无则将其管辖范围内顶级域名（如.com、.cn等）服务器 IP 告诉本地 DNS 服务器。

（6）询问顶级域名服务器

顶级域名服务器收到请求后查看区域文件记录，若无记录则将其管辖范围内权威域名服务器的 IP 地址告诉本地 DNS 服务器。

（7）询问权威域名（主域名）服务器

权威域名服务器接受到请求后查询自己的缓存，如果没有则进入下一级域名服务器进行查找，并重复该步骤直至找到正确记录。

（8）保存结果至缓存

本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时将该结果反馈给客户端，客户端通过这个 IP 地址即可访问目标Web服务器。至此，DNS递归查询的整个过程结束。

为什么DNS既使用TCP又使用UDP？

DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议;

DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。

区域传输是DNS的事务，对准确性要求比较高，而且会产生大于512字节的数据包，因此使用TCP协议。

为什么既使用TCP又使用UDP？

首先了解一下TCP与UDP传送字节的长度限制。

UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。

区域传送时使用TCP，主要有一下两点考虑

  1. 辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
  2. TCP是一种可靠的连接，保证了数据的准确性。

域名解析时使用UDP协议

客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

大多数情况下，DNS解析请求和响应都很小，使用UDP协议更加高效，虽然没有TCP可靠，但是速度快，消耗的系统资源更少，非常适合少量数据包的传输。
一些DNS事务，比如区域传输或其他附加查询，可能会产生大于512字节的数据包，因此使用TCP更加可靠，使用TCP会减少丢包和重新发包的情况，因此更加可靠与高效。

HTTP协议

HTTP 简介：

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。

HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

HTTP 特点：

  1. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

  2. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

  3. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

  4. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

  5. 支持B/S及C/S模式。

HTTP 状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

1xx：指示信息–表示请求已接收，继续处理

2xx：成功–表示请求已被成功接收、理解、接受

3xx：重定向–要完成请求必须进行更进一步的 *** 作

4xx：客户端错误–请求有语法错误或请求无法实现

5xx：服务器端错误–服务器未能实现合法的请求

常见状态码：

200 OK                      //客户端请求成功
400 Bad Request             //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized            //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden               //服务器收到请求，但是拒绝提供服务
404 Not Found               //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error   //服务器发生不可预期的错误
503 Server Unavailable      //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP状态码 | 菜鸟教程 (runoob.com)

HTTP 请求方法

根据HTTP标准，HTTP请求可以使用多种请求方法。

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

GET     请求指定的页面信息，并返回实体主体。
HEAD     类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST     向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT     从客户端向服务器传送的数据取代指定的文档的内容。
DELETE      请求服务器删除指定的页面。
CONNECT     HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS     允许客户端查看服务器的性能。
TRACE     回显服务器收到的请求，主要用于测试或诊断。
HTTP 的请求头

HTTP头字段(HTTP header fields),是指在超文本传输协议(HTTP)的请求和响应消息中的消息头部分

它们定义了一个超文本传输协议事务中的 *** 作参数

HTTP头部字段可以自己根据需要定义，因此可能在 Web服务器和浏览器上发现非标准的头字段

下面是一个HTTP请求的请求头：

GET /home.html HTTP/1.1 Host: developer.mozilla.org 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate, br 
Referer: https://developer.mozilla.org/testpage.html 
Connection: keep-alive 
Upgrade-Insecure-Requests: 1 
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT 
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a" 
Cache-Control: max-age=0

常见的请求字段如下表所示：

字段名说明示例
Accept能够接受的回应内容类型（Content-Types）Accept: text/plain
Accept-Charset能够接受的字符集Accept-Charset: utf-8
Accept-Encoding能够接受的编码方式列表Accept-Encoding: gzip, deflate
Accept-Language能够接受的回应内容的自然语言列表Accept-Language: en-US
Authorization用于超文本传输协议的认证的认证信息Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令Cache-Control: no-cache
Connection该浏览器想要优先使用的连接类型Connection: keep-alive Connection: Upgrade
Cookie服务器通过 Set- Cookie （下文详述）发送的一个 超文本传输协议CookieCookie: $Version=1; Skin=new;
Content-Length以 八位字节数组 （8位的字节）表示的请求体的长度Content-Length: 348
Content-Type请求体的 多媒体类型Content-Type: application/x-www-form-urlencoded
Date发送该消息的日期和时间Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect表明客户端要求服务器做出特定的行为Expect: 100-continue
Host服务器的域名(用于虚拟主机 )，以及服务器所监听的传输控制协议端口号Host: en.wikipedia.org:80 Host: en.wikipedia.org
If-Match仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的 *** 作。主要作用时，用作像 PUT 这样的方法中，仅当从用户上次更新某个资源以来，该资源未被修改的情况下，才更新该资源If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since允许在对应的内容未被修改的情况下返回304未修改If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match允许在对应的内容未被修改的情况下返回304未修改If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range如果该实体未被修改过，则向我发送我所缺少的那一个或多个部分；否则，发送整个新的实体If-Range: “737060cd8c284d8af7ad3082f209582d”
Range仅请求某个实体的一部分Range: bytes=500-999
User-Agent浏览器的浏览器身份标识字符串User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Origin发起一个针对 跨来源资源共享 的请求Origin: http://www.example-social-network.com
HTTP工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是 HTTP 请求/响应的步骤：

1、客户端连接到Web服务器

一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com。

2、发送HTTP请求

通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3、服务器接受请求并返回HTTP响应

Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4、释放连接TCP连接

若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5、客户端浏览器解析HTML内容

客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接

3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;

4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;

5、释放TCP连接;

6、浏览器将该 html 文本并显示内容;

GET和POST请求的区别

GET请求

GET /users/?sex=man&name=kunaly HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

POST请求

POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive

name=kunaly%20Ajax&publisher=Wiley

1、GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=kunaly&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体中。

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

**2、传输数据的大小：**首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。

而在实际开发中存在的限制主要有：

GET: 特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于 *** 作系统的支持。

因此对于GET提交时，传输数据就会受到URL长度的 限制。

POST: 由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3、安全性

POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存；(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击。

URI和URL的区别

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。

URI一般由三部组成：

①访问资源的命名机制

②存放资源的主机名

③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。

采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：

①协议(或称为服务方式)

②存有该资源的主机IP地址(有时也包括端口号)

③主机资源的具体地址。如目录和文件名等

HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。

也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？

Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个用户 *** 作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

session 认证流程：

  1. 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
  2. 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
  3. 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
  4. 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面 *** 作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Cookie 的作用是什么?和Session 有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息，比如：

① 我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；

② 一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；

③ 登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个用户 *** 作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

Cookie和Session的区别（面试必备）

Cookie 和 Session 的区别

  • 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
  • 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
  • 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
  • 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。
什么是 Token（令牌）
  • 访问资源接口（API）时所需要的资源凭证
  • 简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）
  • 特点：
    服务端无状态化、可扩展性好
    支持移动端设备
    安全
    支持跨程序调用

token 的身份验证流程：


1、客户端使用用户名跟密码请求登录
2、服务端收到请求，去验证用户名与密码
3、验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4、客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5、客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6、服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里

基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

token 完全由应用管理，所以它可以避开同源策略

另外一种 token——refresh token

refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的 *** 作。

Access Token 的有效期比较短，当 Acesss Token 由于过期而失效时，使用 Refresh Token 就可以获取到新的 Token，如果 Refresh Token 也失效了，用户就只能重新登录了。

Refresh Token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。

Token 和 Session 的区别

  • Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。
  • Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
  • 所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。
HTTP 和 HTTPS 的区别？

**HTTP协议（超文本传输协议）**被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：xyk号、密码等支付信息。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS和HTTP的主要区别

  1. https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

  2. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。

  3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

  4. http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

Https加密过程

  1. 客户端发起HTTPS请求

  2. 服务端的配置

    采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。这套证书其实就是一对公钥和私钥（私钥1）。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

  3. 传送证书

    这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

  4. 客户端解析证书

    这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会d出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值(私钥2)。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

  5. 传送加密信息

    这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

  6. 服务端解密信息

    服务端用私钥1解密后，得到了客户端传过来的随机值(私钥2)，然后把内容通过该随机值进行对称加密，将信息和私钥2通过某种算法混合在一起，这样除非知道私钥2，不然无法获取内容，而正好客户端和服务端都知道这个私钥2，所以只要加密算法够彪悍，私钥2够复杂，数据就够安全。

  7. 传输加密后的信息

    这部分信息就是服务端用私钥2加密后的信息，可以在客户端用随机值解密还原。

  8. 客户端解密信息

    客户端用之前生产的私钥2解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

  • Client Hello:握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息
  • Server Hello:第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
  • Certificate:这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥
  • Server Hello Done:通知客户端 Server Hello 过程结束。
  • Certificate Verify:客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3生成 PreMaster Key
  • Client Key Exchange:上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。
  • Change Cipher Spec(Client):这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息
  • Encrypted Handshake Message(Client):这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的
  • Change Cipher Spec(Server):这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息
  • Encrypted Handshake Message(Server):这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
  • Application Data:到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输
对称加密

对称加密就是指，加密和解密使用同一个密钥的加密方式。

发送方使用密钥将明文数据加密成密文，然后发送出去，接收方收到密文后，使用同一个密钥将密文解密成明文读取。

非对称加密

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（public key）和私有密钥（private key）。

公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

在HTTPS中，这两种加密方式混合使用

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

数字证书认证

由于公钥在下发的时候也容易被替换劫持，所以需要个第三方认证机构确认公钥的正确性

CA：数字证书认证机构，是客户端服务端都认可的第三方机构，负责数字签名服务端公钥

**数字签名：**签名就是一种证明身份的机制，是一种校验机制（简单说是用私钥加密内容的hash,公钥解密对比hash判断内容是否完整）

**数字证书：**由一个可信的组织验证和签发的识别信息。

HTTPS中数字认证流程如下:

HTTP1.0、HTTP2.0 、HTTP3的区别

HTTP1.x 有连接无法重复使用、队头堵塞、协议开销大和安全因素等诸多缺陷（TCP）。
HTTP2 通过二进制流、多路复用、header压缩等技术大大提高了性能（TCP）。
HTTP3是基于UDP实现的，该协议基于UDP又吸取了TCP的精华，实现了快又可靠的协议。

HTTP1.0、HTTP1.1、HTTP2.0 、HTTP3

计算机网络的地址的分类

计算机网络地址共分为五类：A类、B类、C类、D类、E类。

A类地址:0-127

A类地址的表示范围为：0.0.0.0~126.255.255.255，默认网络掩码为：255.0.0.0；A类地址分配给规模特别大的网络使用。A类网络用第一组数字表示网络本身的地址，后面三组数字作为连接于网络上的主机的地址。分配给具有大量主机（直接个人用户）而局域网络个数较少的大型网络。例如IBM公司的网络。

B类地址：128-191

B类地址的表示范围为：128.0.0.0~191.255.255.255，默认网络掩码为：255.255.0.0；B类地址分配给一般的中型网络。B类网络用第一、二组数字表示网络的地址，后面两组数字代表网络上的主机地址。

C类地址：192-223

C类地址的表示范围为：192.0.0.0~223.255.255.255，默认网络掩码为：255.255.255.0；C类地址分配给小型网络，如一般的局域网和校园网，它可连接的主机数量是最少的，采用把所属的用户分为若干的网段进行管理。C类网络用前三组数字表示网络的地址，最后一组数字作为网络上的主机地址。

D类地址：

D类地址主要是用于组播，前面4位主要起的作用是引导，后面28位位组播的地址ID。

E类地址：

总是以1111四位引导 ，E类地址用于研究用。

特殊的IP地址

1.网络地址：

IP中主机地址为0的地址表示网络地址，如128.211.0.0。

2.广播地址：

网络号后跟所有位全是1的后缀，就是直接广播地址。

3.回送地址：

即127.0.0.1，用于测试。

IP地址与子网掩码相与得到网络号：

ip : 192.168.2.110

&

Submask : 255.255.255.0

----------------------------

网络号 ：192.168.2 .0

注:

主机号，全为0的是网络号（例如：192.168.2.0），主机号全为1的为广播地址（192.168.2.255）

Socket 通信流程

什么是Socket

Socket就是一组API，对TCP/IP协议进行封装的API！

可以将Socket理解为处于传输层和应用层之间的一个抽象层，它把TCP/IP层复杂的 *** 作抽象为几个简单的接口供应用层调用以实现进程在网络中通信。

Socket通信流程图如下：

简单描述一下Socket的通信流程：

  1. 服务端这边首先创建一个Socket（Socket()），然后绑定IP地址和端口号（Bind()），之后注册监听（Listen()），这样服务端就可以监听指定的Socket地址了；
  2. 客户端这边也创建一个Socket（Socket()）并打开，然后根据服务器IP地址和端口号向服务器Socket发送连接请求（Connect()）；
  3. 服务器Socket监听到客户端Socket发来的连接请求之后，被动打开，并调用Accept()函数接收请求，这样客户端和服务器之间的连接就建立好了；
  4. 成功建立连接之后就可以进行数据交互了，客户端和服务器进行数据交互（Receive()、Send()）；
    在数据传输完成之后，各自关闭连接（Close()），交互结束；
客户端与服务端长连接的几种方? WebSocket？

在日常 Web 项目中，通常使用的是短连接。即一个 Request 对应一个 Response，发起请求后建立TCP 连接，数据传输后连接关闭。但是对于股票信息更新、即时通讯、在线游戏这种数据交互频繁的场景就需要使用长连接。今天记录一下长连接的几种方式。

一、ajax 轮询

实现原理：ajax 轮询指客户端每间隔一段时间向服务端发起请求，保持数据的同步。

优点：可实现基础（指间隔时间较短）的数据更新。

缺点：这种方法也只是尽量的模拟即时传输，但并非真正意义上的即时通讯，很有可能出现客户端请求时，服务端数据并未更新。或者服务端数据已更新，但客户端未发起请求。导致多次请求资源浪费，效率低下。

二、long poll 长轮询

实现原理：

long poll 指的是客户端发送请求之后，如果没有数据返回，服务端会将请求挂起放入队列（不断开连接）处理其他请求，直到有数据返回给客户端。然后客户端再次发起请求，以此轮询。在 HTTP1.0 中客户端可以设置请求头 Connection:keep-alive，服务端收到该请求头之后知道这是一个长连接，在响应报文头中也添加 Connection:keep-alive。客户端收到之后表示长连接建立完成，可以继续发送其他的请求。在 HTTP1.1 中默认使用了 Connection:keep-alive 长连接。

优点：减少客户端的请求，降低无效的网络传输，保证每次请求都有数据返回，不会一直占用线程。

缺点：无法处理高并发，当客户端请求量大，请求频繁时对服务器的处理能力要求较高。服务器一直保持连接会消耗资源，需要同时维护多个线程，服务器所能承载的 TCP 连接数是有上限的，这种轮询很容易把连接数顶满。每次通讯都需要客户端发起，服务端不能主动推送。

三、iframe 长连接

实现原理：

在网页上嵌入一个 iframe 标签，该标签的 src 属性指向一个长连接请求。这样服务端就可以源源不断地给客户端传输信息。保障信息实时更新。

优点：消息及时传输。

缺点：消耗服务器资源。

四、WebSocket

实现原理：

Websocket 实现了客户端与服务端的双向通信，只需要连接一次，就可以相互传输数据，很适合实时通讯、数据实时更新等场景。

Websocket 协议与 HTTP 协议没有关系，它是一个建立在 TCP 协议上的全新协议，为了兼容 HTTP 握手规范，在握手阶段依然使用 HTTP 协议，握手完成之后，数据通过 TCP 通道进行传输。

Websoket 数据传输是通过 frame 形式，一个消息可以分成几个片段传输。这样大数据可以分成一些小片段进行传输，不用考虑由于数据量大导致标志位不够的情况。也可以边生成数据边传递消息，提高传输效率。

与 HTTP 的区别：

以下是一个 WebSoket 协议的请求响应报文头，与 HTTP 协议的区别是：

  1. URL是以 ws: 开头，如果是对应的 HTTPS，则以 wss: 开头。WebSocket 使用 ws 或 wss 为统一资源标志符，其中 wss 表示在 TLS 之上的 Websocket。

  2. Status Code：101。该状态码表示协议切换。服务器返回了 101 ，表示没有释放 TCP 连接。WebSoket 协议握手阶段还是依赖于 HTTP 协议，到数据传输阶段便切换协议。

  3. Conection：upgrade，表示协议升级。在 HTTP 协议中，该请求头有两个值，一个是 close ， HTTP/1.0 默认值，表示客户端或服务端想要关闭连接。另一个是 keep-alive，HTTP/1.1 默认值，表示长连接。

  4. 以下头部字段是只有 WebSocket 协议才有的字段。

    • 请求头：
      Sec-WebSocket-Extension：表示客户端协商的拓展特性。
      Sec-WebSocket-Key：是一个 Base64 encode 的密文，由浏览器随机生成，用来验证是否是 WebSocket 协议。
      Sec-WebSocket-Version：表示 WebSocket 协议版本。

    • 响应头：
      Sec-WebSocket-Extension：表示服务端支持的拓展特性。
      Sec-WebSocket-Accept：与客户端的 Sec-WebSocket-Key 相对应，是经过服务器确认，加密过后的 Sec-WebSocket-Key。

优点：

双向通信。客户端和服务端双方都可以主动发起通讯。

没有同源限制。客户端可以与任意服务端通信，不存在跨域问题。

数据量轻。第一次连接时需要携带请求头，后面数据通信都不需要带请求头，减少了请求头的负荷。

传输效率高。因为只需要一次连接，所以数据传输效率高。

缺点：

长连接需要后端处理业务的代码更稳定，推送消息相对复杂；

长连接受网络限制比较大，需要处理好重连。

兼容性，WebSocket 只支持 IE10 及其以上版本。

服务器长期维护长连接需要一定的成本，各个浏览器支持程度不一；

成熟的 HTTP 生态下有大量的组件可以复用，WebSocket 则没有，遇到异常问题难以快速定位快速解决。

欢迎分享，转载请注明来源：内存溢出

原文地址: https://outofmemory.cn/langs/795714.html

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
code code 管理员组
0 0
上一篇 2022-05-06
下一篇 2022-05-06

发表评论

登录后才能评论

评论列表（0条）

保存