计算机网络¶

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（报文段往返时间）来自适应调整的

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 goes here-->
      </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不会被删除，其存在时间是长期的。

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还在，只有等到了销毁的时间会自动销毁。

计算机网络¶

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

通信交互方式¶

MAC地址和IP地址¶

ARP协议的作用¶

ping发生了什么¶

traceroute发生了什么¶

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

区别¶

应用场景¶

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

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

TCP超时重传¶

TCP拥塞机制¶

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

TCP三次握手及三次缘由¶

TCP四次挥手及四次缘由¶

TIME-WAIT状态及2MSL时间¶

域名系统DNS¶

统一资源定位符URL¶

描述一下HTTP协议¶

概述¶

特点¶

HTTP工作原理¶

HTTP2¶

HTTP持久连接与管线化¶

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

GET和POST区别¶

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

HTTP状态码¶

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

IP/TCP/UDP分片¶

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

数字签名和数字证书¶

HTTP和HTTPS的区别¶

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

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

cookie和session¶

cookie¶

工作流程¶

基础知识¶

session¶

工作流程¶

基础知识¶

区别¶

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

ping发生了什么 ¶

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

TCP拥塞机制 ¶

描述一下HTTP协议 ¶

HTTP2 ¶

数字签名和数字证书 ¶