计算机网络知识高频面试题

- 日理万妓 2022-10-16 13:28 316阅读 0赞

# 计算机网络 #

>  *  OSI七层协议及TCP/IP四层协议
>  *  通信交互方式
>  *  MAC地址和IP地址
>  *  ARP协议的作用
>  *  ping发生了什么
>  *  traceroute发生了什么
>  *  TCP/UDP的区别和应用场景
>  *  拥塞控制和流量控制的区别
>  *  TCP滑动窗口实现流量控制
>  *  TCP超时重传
>  *  TCP拥塞机制
>  *  TCP三次握手及三次缘由
>  *  TCP四次挥手及四次缘由
>  *  TIME-WAIT状态及2MSL时间
>  *  域名系统DNS
>  *  统一资源定位符URL
>  *  描述一下HTTP协议
>  *  HTTP2.0
>  *  HTTP持久连接与管线化
>  *  HTTP协议请求报文具体信息
>  *  GET和POST的区别
>  *  HTTP协议响应报文具体信息
>  *  HTTP状态码
>  *  浏览器键入URL后的访问流程
>  *  IP/TCP/UDP分片
>  *  对称密钥和公钥密码体制
>  *  数字签名和数字证书
>  *  HTTP和HTTPS的区别
>  *  运输层安全协议及SSL工作过程
>  *  HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？
>  *  cookie和session
>  *  浏览器关闭后，session就销毁了吗

## OSI七层协议及TCP/IP四层协议 ##

*  七层协议：物、数、网、传、会、表、应
    
     *  物理层 RJ45
     *  数据链路层 PPP，IEEE 802.3/802.2
     *  网络层 IP，ARP
     *  传输层 TCP，UDP
     *  会话层
     *  表示层 TIFF，GIF，JPEG,
     *  应用层 DNS，HTTP，FTP
 *  四层协议：数据链路层（物理层，数据链路层），网络层（网络层），传输层（传输层），应用层（会话层，表示层，应用层）
    
     *  数据链路层： PPP**MAC不属于协议，只是一个地址**
     *  网络层：IP、ARP、ICMP
     *  传输层：TCP、UDP
     *  应用层：DNS、HTTP、FTP

## 通信交互方式 ##

*  单工通信
    
     *  只能有一个方向的通信没有反方向的交互
 *  半双工通信
    
     *  双方可以发送消息，但不能同时发送。可以交替进行一方发送、另一方接收
 *  全双工通信
    
     *  通信的双方可以同时发送和接收信息

## MAC地址和IP地址 ##

*  MAC地址又叫硬件地址或物理地址，它不是地址位置，实际上是适配器地址，每一台计算机中固化在适配器的ROM中的地址，作用是用来定义网络设备的位置
 *  IP地址是IP协议提供的一种统一的地址格式，为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异
 *  两者的区别
    
     *  物理地址是数据链路层和物理层使用的地址，放在MAC帧的首部
     *  IP地址是网络层和以上各层使用的地址，放在IP数据报的首部

## ARP协议的作用 ##

网络层使用的是IP地址，数据链路层使用的是硬件地址。  
ARP协议的用途是为了从网络层使用的IP地址，解析出数据链路层使用的硬件地址。

*  在主机ARP高速缓存中存放一个从IP地址到硬件地址的映射表
 *  当需要解析时，先去arp缓存表(存着ip-mac对应关系)去查找目标ip的mac地址
 *  如果查到了，将目标ip的mac地址封装到链路层数据报
 *  如果缓存中没有找到，会发起一个广播：who is ip XXX tell ip XXX，所有收到的广播的机器看这个ip是不是自己的，如果是自己的，则以单播的形式将自己的mac地址回复给请求的机器

## ping发生了什么 ##

ping主要是为了测试两台主机之间的连通性，通过应用层直接使用网络层ICMP，没有通过运输层TCP和UDP，是通过发送ICMP报文回显请求实现。

>  *  A主机构建一个ICMP格式的数据包，通过ICMP协议把该数据包和B主机的IP地址一起交给IP协议；
>  *  IP层构建一个数据包（A主机的IP地址+控制信息+B主机的IP地址），获得B主机的MAC地址，以便构建一个数据帧(IP协议会根据B主机的IP地址和自己的子网掩码判断是不是属于同一层网络,如果是属于同一层网络的话,就会获得B主机的MAC地址，如果以前两机有过通信，在A机的ARP缓存表应该有B机IP与其MAC的映射关系，如果没有，就发一个ARP请求广播，得到B机的MAC)
>  *  主机B接受到主机A的发过来的数据帧以后，先检查该帧中包含的B的IP地址，并和本地的物理地址进行比对，如果符合的话，就接受，否则，就抛弃。同样，需要将该数据帧交由自己的IP层协议，IP层检查以后，再交由ICMP协议，构建一个ICMP的应答包，发送给主机A。

## traceroute发生了什么 ##

traceroute用来跟踪一个分组从源点到终点的路径，及到达其中每一个路由器的往返时间

*  通过发送UDP报文，设置目的端口为一个不可能的值
 *  将IP首部中的TTL分别设置从1到N，每次逐个增加
 *  每次设置TTL后，重新发送数据报，路由器接收到数据报后，将TTL减1，若当前的路由器接收到数据报，发现TTL为1时，会将TTL减1变为0，然后丢弃数据报，发送ICMP时间超过报文
 *  如果最后一个数据报刚刚达到主机，数据报的TTL是1，此时主机不把TTL减1
 *  因IP数据报中封装的是无法交付的UDP数据报，此时目的主机向源主机发送ICMP终点不可达差错报文，表示达到目的主机

## TCP/UDP的区别和应用场景 ##

\#\#\#区别  
TCP，全称：传输控制协议，面向连接的安全的流式传输协议  
UDP，全称：用户数据报协议，面向无连接的不安全的报式传输协议

*  连接
    
     *  TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接。
     *  UDP无连接。
 *  服务对象
    
     *  TCP是点对点的两点间服务，即一条TCP连接只能有两个端点
     *  UDP支持一对一，一对多，多对一，多对多的交互通信。
 *  可靠性
    
     *  TCP是可靠交付：无差错，不丢失，不重复，按序到达。
     *  UDP是尽最大努力交付，不保证可靠交付。
 *  拥塞控制，流量控制
    
     *  TCP有拥塞控制和流量控制保证数据传输的安全性。
     *  UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。
 *  报文长度
    
     *  TCP是动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的，流式传输
     *  UDP面向报文，不合并，不拆分，保留上面（应用层）传下来报文的边界，直接传输报文。
 *  首部开销
    
     *  TCP首部开销大，首部20个字节。
     *  UDP首部开销小，8字节。（源端口，目的端口，UDP数据报长度，检验和，每个字段两个字节）

### 应用场景 ###

*  要求通信数据完整性，则应该选用TCP协议（如文件传输、重要状态的更新，登录数据传输等）
 *  要求通信实时性，使用 UDP 协议（如视频传输，通话，屏幕共享软件）

## 拥塞控制和流量控制的区别 ##

*  拥塞控制是防止过多的数据注入到网络中，可以使网络中的路由器或链路不致过载，是一个全局性的过程。
 *  流量控制是点对点通信量的控制，是一个端到端的问题，主要就是抑制发送端发送数据的速率，以便接收端来得及接收

## TCP滑动窗口实现流量控制 ##

*  流量控制是让发送方的发送速率不要太快，要让接收方来得及接收，实现对发送方的流量控制.
 *  滑动窗口出现的原因：在确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是性能比较差，尤其是数据往返的时间长的时候
 *  滑动窗口以字节为单位，而不是报文

## TCP超时重传 ##

*  保证了数据的可靠传输，对于一些出错，丢包等问题TCP设计了超时与重传机制。
 *  基本原理：在发送一个数据之后，就开启一个定时器，并设置RTO，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。
 *  不同的网络情况不一样，不可能设置一样的RTO（超时重传时间），实际中RTO是根据网络中的RTT（报文段往返时间）来自适应调整的

## TCP拥塞机制 ##

*  拥塞的标志
    
     *  超时重传
     *  3次重复的ACK

慢启动，拥塞避免，快恢复，快重传

## ACK SYN FIN解释及是否消耗序列号 ##

*  ACK 确认标志位，ACK可以携带数据，若不携带，则不消耗序列号
 *  SYN 同步标志位，SYN不能携带数据，必须消耗一个序列号
 *  FIN 终止标志位，FIN可以携带数据，必须消耗一个序列号

## TCP三次握手及三次缘由 ##

*  **为什么TCP三次握手，不能两次或者四次吗？**
    
     *  三次握手是为了防止，客户端的请求报文在网络滞留，客户端超时重传了请求报文，服务端建立连接，传输数据，释放连接之后，服务器又收到了客户端滞留的请求报文，建立连接一直等待客户端发送数据。
     *  服务器对客户端的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果客户端并没有收到服务器的回应呢？此时，客户端仍认为连接未建立，服务器会对已建立的连接保存必要的资源，如果大量的这种情况，服务器会崩溃。
     *  服务器端给客户端发送同步及确认报文时可以合并，四次会浪费时间

## TCP四次挥手及四次缘由 ##

四次报文中服务器端发送给客户端的请求关闭连接报文FIN和ACK也是合并的，相对于三次来说，只是前面多了一次ACK的确认。

*  **为什么TCP四次挥手，不能三次吗？**
    
     *  当客户端确认发送完数据且知道服务器已经接收完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给服务器。
     *  服务器收到客户端发送的FIN，表示收到了，就会发送ACK回复。
     *  但这时候服务器可能还在发送数据，没有想要关闭数据口的意思，所以服务器的FIN与ACK不是同时发送的，而是等到服务器数据发送完了，才会发送FIN给客户端。
     *  客户端收到服务器发来的FIN，知道服务器的数据也发送完了，回复ACK， 客户端等待2MSL以后，没有收到服务器传来的任何消息，知道服务器已经收到自己的ACK了，客户端就关闭链接，服务器也关闭链接（服务器比客户端早关闭）。

## TIME-WAIT状态及2MSL时间 ##

*  四次挥手期间，客户端和服务器端都可主动释放连接，谁主动释放，谁将进入TIME\_WAIT状态
 *  MSL是最长报文寿命，一般为2分钟，2MSL即4分钟
 *  为什么TIME-WAIT状态必须等待2MSL时间？
    
     *  \*\*保证最后一次挥手报文能到B，能进行超时重传。\*\*若B收不到A的ACK报文，则B会超时重传FIN+ACK，A会在2MSL时间内收到重传报文段，然后发送ACK，重新启动2MSL计时器
     *  2MSL后，本次连接的所有报文都会消失，不会影响下一次连接。

## 域名系统DNS ##

用于将域名转换为IP地址。  
DNS解析过程有两种，分别是递归查询和迭代查询。

*  递归查询
    
     *  若主机询问的本地域名服务器不知道被查询域名的IP地址，本地域名服务器以DNS客户身份，向其他根域名服务器继续发出查询请求报文（代替该主机继续查询），而不是该主机自己进行下一步查询
 *  迭代查询
    
     *  当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出IP地址，要么告诉本地域名服务器，应该向哪一个域名服务器进行查询，然后本地域名服务器进行后续查询

## 统一资源定位符URL ##

统一资源定位符URL，用来表示从互联网上得到的资源位置。

*  一般由四个部分组成
    
     *  <协议>://<主机>:<端口>/<路径>
     *  主机一般为域名，需要通过DNS系统解析出IP
 *  使用HTTP的URL
    
     *  http://<主机>:<端口>/<路径>

## 描述一下HTTP协议 ##

### 概述 ###

*  HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web）服务器传输超文本到本地浏览器的传送协议。
 *  HTTP属于应用层协议，基于TCP/IP通信协议来传递数据

### 特点 ###

*  灵活
    
     *  HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
 *  无连接
    
     *  无连接的含义是通信双方在交换HTTP报文之前不需要建立HTTP连接
 *  无状态
    
     *  无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时应答较快。
 *  支持B/S和C/S模式
 *  默认端口80
 *  基于TCP协议

### HTTP工作原理 ###

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。

*  客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。
 *  服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

**HTTP 请求/响应的步骤**

>  *  **客户端连接到Web服务器**  
>     一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
>  *  **发送HTTP请求**  
>     通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
>  *  **服务器接受请求并返回HTTP响应**  
>     Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
>  *  **释放连接TCP连接**  
>     若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
>  *  **客户端浏览器解析HTML内容**  
>     客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

## HTTP2 ##

*  新的二进制格式（Binary Format）
    
     *  HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
 *  多路复用（MultiPlexing）
    
     *  即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
     *  pipelining在接收response返回时，必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。这种情况就如图中第三种，第一个请求阻塞后，后面的请求都需要等待，这也就是队头阻塞
 *  header压缩
    
     *  对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小
 *  服务端推送
    
     *  我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了

## HTTP持久连接与管线化 ##

HTTP协议首先要和服务器建立TCP连接，这需要三次握手。

*  请求一个万维网文档的时间
    
     *  当建立TCP连接的三次握手前两次完成后，即经过一个RTT时间，万维网客户就把HTTP请求报文，作为建立TCP连接的三次握手中的第三次的数据，发送给万维网服务器，服务器收到HTTP请求后，把请求的文档作为响应报文返回给客户。
     *  文档传输时间+2\*RTT
 *  HTTP1.0非持久连接的缺点
    
     *  每请求一个文档，需要两倍RTT的开销。服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接，然后重新建立连接发出请求
 *  HTTP1.1持久连接
    
     *  万维网服务器在发送响应后仍然在一段时间内保持这段连接，可以使得同一用户继续在该连接上传送后续请求和响应报文
 *  持久连接的两种工作方式
    
     *  非管线化
        
         *  发送请求后需等待并收到回应，才能发送下一个请求
     *  管线化
        
         *  不用等待响应，直接发送下一个请求，但接收的时候必须按照顺序接收，如果有一个请求阻塞，则接收会全部阻塞

## HTTP协议请求报文具体信息 ##

HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据四个部分组成

*  **GET**
    
        GET /562f25980001b1b106000338.jpg HTTP/1.1
        Host:img.mukewang.com
        User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64)
        AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
        Accept:image/webp,image/*,*/*;q=0.8
        Referer:http://www.imooc.com/
        Accept-Encoding:gzip, deflate, sdch
        Accept-Language:zh-CN,zh;q=0.8
        空行
        请求数据为空
 *  **POST**
    
        POST / HTTP1.1
        Host:www.wrox.com
        User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
        Content-Type:application/x-www-form-urlencoded
        Content-Length:40
        Connection: Keep-Alive
        空行
        name=Professional%20Ajax&publisher=Wiley

>  *  **请求行**，用来说明请求类型,要访问的资源以及所使用的HTTP版本.  
>     GET说明请求类型为GET，/562f25980001b1b106000338.jpg(URL)为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
>  *  **请求头部**，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
>     
>      *  HOST，给出请求资源所在服务器的域名.
>      *  User-Agent，HTTP客户端程序的信息，该信息由你发出请求使用的浏览器来定义,并且在每个请求中自动发送等
>      *  Accept，说明用户代理可处理的媒体类型
>      *  Accept-Encoding，说明用户代理支持的内容编码
>      *  Accept-Language，说明用户代理能够处理的自然语言集
>      *  Content-Type，说明实现主体的媒体类型
>      *  Content-Length，说明实现主体的大小
>      *  Connection，连接管理，可以是Keep-Alive或close
>  *  **空行**，请求头部后面的空行是必须的即使第四部分的请求数据为空，也必须有空行。
>  *  **请求数据**也叫主体，可以添加任意的其他数据。

## GET和POST区别 ##

GET /books/?sex=man&name=Professional 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
    空行
    请求数据为空

*  区别
    
     *  **get参数通过url传递，post放在request body中**，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
     *  **POST的安全性要比GET的安全性高**，一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码.
     *  **get请求在url中传递的参数是有长度限制的，而post没有**
     *  **GET产生一个TCP数据包，POST产生两个TCP数据包**。
        
         *  对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
         *  对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

## HTTP协议响应报文具体信息 ##

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

HTTP/1.1 200 OK
    Date: Fri, 22 May 2009 06:07:21 GMT
    Content-Type: text/html; charset=UTF-8
    <html>
          <head></head>
          <body>
                
          </body>
    </html>

>  *  状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。  
>     第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为OK
>  *  消息报头，用来说明客户端要使用的一些附加信息  
>     第二行和第三行为消息报头，Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
>  *  空行，消息报头后面的空行是必须的
>  *  响应正文，服务器返回给客户端的文本信息。空行后面的html部分为响应正文

## HTTP状态码 ##

*  1xx：指示信息–表示请求已接收，继续处理。
 *  2xx：成功–表示请求正常处理完毕。
    
     *  200 OK：客户端请求被正常处理
     *  206 Partial content：客户端进行了范围请求
 *  3xx：重定向–要完成请求必须进行更进一步的操作。
    
     *  301 Moved Permanently：永久重定向，该资源已被永久移动到新位置，将来任何对该资源的访问都要使用本响应返回的若干个URI之一
     *  302 Found：临时重定向，请求的资源现在临时从不同的URI中获得
 *  4xx：客户端错误–请求有语法错误，服务器无法处理请求。
    
     *  400 Bad Request：请求报文存在语法错误
     *  403 Forbidden：请求被服务器拒绝
     *  404 Not Found：请求不存在，服务器上找不到请求的资源
 *  5xx：服务器端错误–服务器处理请求出错。
    
     *  500 Internal Server Error：服务器在执行请求时出现错误
     *  503 Service Unavaliable：服务器正在停机维护

## 浏览器键入URL后的访问流程 ##

*  浏览器使用**DNS协议**向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址，其中DNS服务器是基于UDP的，因此会用到**UDP协议**;
 *  解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接，会使用到**TCP协议**;
 *  然后浏览器就要与服务器建立一个http连接，因此要用到**http协议**，http生成一个get请求报文，如果采用https还会使用**https协议**对http数据进行加密，涉及到**SSL协议**，将报文发送到TCP层
 *  TCP层如果有需要先将HTTP数据包分片，分片依据MTU和MSS（ mtu是网络传输最大报文包,mss是网络传输数据最大值）。
 *  TCP的数据包然后会发送给IP层，用到**IP协议**。IP层通过路由选路，一跳一跳发送到目的地址。
 *  当然在一个网段内的寻址是通过以太网协议实现，**以太网协议**需要知道目的IP地址的物理地址，则需要**ARP协议**。
 *  服务器端接收到请求，然后发送返回响应请求
 *  释放 TCP连接(若connection为close，则释放TCP连接，若为keep-alive则不会释放);
 *  浏览器将该解析html文本并显示内容

## IP/TCP/UDP分片 ##

数据发送时，将数据从应用层->传输层->网络层->数据链路层，其中传输层是TCP和UDP，网络层是IP协议。

*  MTU以太网帧的长度为1500字节，所能接收的传输层数据段最大为 1480 个字节（以太网帧中的数据包括 IP 协议的报头信息，IP 协议的报头信息为 20 字节）
 *  在计算 MSS （网络传输数据最大值）的时候，用 MTU 减去网络层报头长度以及传输层报头长度即可。
 *  UDP
    
     *  一旦 UDP 携带的数据超过了 1472 （MTU - IP报头 - UDP报头 = 1500 - 20 - 8），那么在 IP 层就会对该数据分片，一旦分片就意味着增加了 UDP 传输丢包的可能性。 由于 UDP 协议传输本身就不负责可靠性，再加上分片，那么丢包的可能性就大大增加

## 对称密钥和公钥密码体制 ##

*  对称密钥密码体制
    
     *  加密密码和解密密码是相同的密钥
 *  公钥密码体制，非对称加密
    
     *  加密密码和解密密码不同
     *  加密和解密算法都是公开的，加密密钥也是公开的，解密密钥是保密的
     *  公钥和私钥是配对关系，公钥加密就用私钥解密，反之亦然

## 数字签名和数字证书 ##

使用公钥密码加密的一般流程：通过A的公钥对报文加密，发送给B，然后B拿A的私钥进行解密，得到报文.  
**注意：并不是每次传输报文的时候都要加数字签名，数字签名一般用于数字证书的验证，这样的话浏览器内置的CA拥有服务端的公钥和私钥。**

*  数字签名
    
     *  普通数字签名(**能核实发送者，但无法保证报文完整性**)
        
         *  A通过A的私钥对报文进行加密，将其附在报文的后面，发送给B，然后B拿A的公钥对附加信息进行解密的过程，为数字签名
         *  上述过程中仅仅实现了数字签名，但并没有对实际报文进行加密。实际操作时，可以通过A–>A私钥(数字签名)–>B公钥(报文加密)–>B私钥(报文解密)–>A公钥(验证数字签名)
     *  密码散列函数
        
         *  使用密码散列函数对报文进行与运算得到hash值，简称摘要
         *  密码散列函数有MD5和安全散列算法SHA
     *  报文摘要数字签名(**核实发送者，保证报文完整性**)  
        对报文本身加密可能是个耗时过程，比如这封Email足够大，那么私钥加密整个文件以及拿到文件后的解密无疑是巨大的开销
        
         *  A先对这封Email执行哈希运算得到hash值简称“摘要”，取名h1
         *  然后用自己私钥对摘要加密，生成的东西叫“数字签名”
         *  把数字签名加在Email正文后面，一起发送给B
         *  防止邮件被窃听你可以用继续B公钥加密
         *  B收到邮件后使用B私钥对报文解密，用A的公钥对数字签名解密，成功则代表Email确实来自A，失败说明有人冒充
         *  B对邮件正文执行哈希运算得到hash值，取名h2
         *  B会对比数字签名的hash值h1和自己运算得到的h2，一致则说明邮件未被篡改。
     *  数字签名的作用
        
         *  确认核实发送者
         *  保证报文的完整性
         *  一般用于验证数字证书
 *  数字证书  
    明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了，由认证中心（CA）或者认证中心的下级认证中心颁发。通俗来说，A确认收到的公钥真的是B的公钥，而不是别人伪造的
    
     *  制作数字签名
        
         *  CA拥有非对称加密的私钥和公钥。
         *  CA对证书明文信息进行hash。
         *  对hash后的值用私钥加密，得到数字签名
         *  明文和数字签名共同组成了数字证书
     *  数字证书验证过程
        
         *  拿到证书，得到明文T，数字签名S。
         *  用CA机构的公钥对S解密，得到S’。（由于是浏览器信任的机构，浏览器保有它的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥）
         *  用证书里说明的hash算法对明文T进行hash得到T’。
         *  比较S’是否等于T’，等于则表明证书可信。

## HTTP和HTTPS的区别 ##

>  *  HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性
>  *  HTTPS可以保证报文完整性，另外可以核实发送者身份
>  *  HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书
>  *  HTTPS在TCP三次握手阶段之后，还需要进行SSL的handshake，协商加密使用的对称加密密钥
>  *  HTTP协议端口是80，HTTPS协议端口是443

## 运输层安全协议及SSL工作过程 ##

*  SSL 安全套接字层协议
 *  TLS 运输层安全协议，在SSL的基础上设计
 *  SSL工作过程
    
     *  协商加密算法
        
         *  浏览器A向服务器B发送SSL版本，及自身支持的加密组件（包括加密算法及密钥长度等）
         *  B从中选择自身支持的加密组件和SSL版本，发送给A
     *  服务器鉴别
        
         *  B向A发送包含公开密钥的数字证书
         *  A对数字证书进行鉴别，获取B的公钥
     *  会话密钥计算
        
         *  A随机产生秘密数，将秘密数通过B的公钥发送给B，之后A通过协商的加密算法产生会话密钥
         *  B接收到秘密数后，通过B的私钥将其解密得到秘密数，然后根据协商加密算法产生会话密钥
     *  安全数据传输
        
         *  双方会互相发送一次数据，用会话密钥加密和解密他们之间传达的数据并验证其完整性
     *  通信
        
         *  上述验证通过后，才继续进行http通信

## HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？ ##

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？用session就行。

*  服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下
 *  之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

## cookie和session ##

HTTP协议作为无状态协议，对于HTTP协议而言，无状态指每次request请求之前是相互独立的，当前请求并不会记录它的上一次请求信息，如何将上下文请求进行关联呢？**客户端（不同的浏览器）记录用户的状态通过cookie，服务器端（不同的网站）记录用户的状态通过session。**

### cookie ###

#### **工作流程** ####

*  客户端请求服务器端，服务器端产生cookie响应头，随响应报文发送给客户端，客户端将cookie文本保存起来
 *  下次客户端再次请求服务端时，会产生cookie请求头，将之前服务器发送的cookie信息，再发送给服务器，服务器就可以根据cookie信息跟踪客户端的状态。

#### **基础知识** ####

Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie，它是服务器端存放在本地机器中的数据，随每一个请求发送给服务器，由于Cookie在客户端，所以可以编辑伪造，不是十分安全。

*  非持久cookie
    
     *  内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。
 *  持久cookie
    
     *  硬盘Cookie保存在硬盘里，有一个过期时间（客户端cookie设置的时间），除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。

### session ###

#### **工作流程** ####

*  当用户第一次访问站点时，服务器端为用户创建一个sessionID，这就是针对这个用户的唯一标识，每一个访问的用户都会得到一个自己独有的session ID，这个session ID会存放在响应头里的cookie中，之后发送给客户端。这样客户端就会拥有一个该站点给他的session ID。
 *  当用户第二次访问该站点时，浏览器会带着本地存放的cookie(里面存有上次得到的session ID)随着请求一起发送到服务器，服务端接到请求后会检测是否有session ID，如果有就会找到响应的session文件，把其中的信息读取出来；如果没有就跟第一次一样再创建个新的。

#### **基础知识** ####

session是存放在服务器里的，所以session 里的东西不断增加会增加服务器的负担，我们会把一些重要的东西放在session里，不太重要的放在客户端cookie里

*  session失效
    
     *  服务器（非正常）关闭时
     *  session过期/失效（默认30分钟）
        
         *  问题：时间的起算点 从何时开始计算30分钟？从不操作服务器端的资源开始计时（例如：当你访问淘宝页面时，点开页面不动，第29分钟再动一下页面，就得重新计时30分钟；当过了30分钟，就失效了。）
     *  手动销毁session
 *  sessionID的传递方式
    
     *  通过cookie传递
     *  当cookie禁用后，可以通过url传递
 *  不同场景下的session
    
     *  当在同一个浏览器中同时打开多个标签，发送同一个请求或不同的请求，仍是同一个session;
     *  当不在同一个窗口中打开相同的浏览器时（打开多个相同的浏览器），发送请求，仍是同一个session;
     *  当使用不同的浏览器时，发送请求，即使发送相同的请求，是不同的session;
     *  当把当前某个浏览器的窗口全关闭，再打开，发起相同的请求时，是不同的session。

### 区别 ###

*  cookie数据存放在客户的浏览器上，session数据放在服务器上。
 *  cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。
 *  session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。
 *  单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
 *  可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中。

## 浏览器关闭后，session就销毁了吗？ ##

浏览器关闭和服务器session销毁没有任何关系，会话Cookie（非持久cookie）在关闭浏览器后就会消失，但是原来服务器的Session还在，只有等到了销毁的时间会自动销毁。