HTTP过程：
①浏览器根据域名解析IP地址
DNS解析
②浏览器与WEB服务器建立一个TCP连接
TCP三次握手
③浏览器给WEB服务器发送一个HTTP请求
HTTP请求报文由请求行、请求头部、空行和请求数据，这四个部分组成
④服务器端响应HTTP请求，浏览器得到HTML代码
HTTP响应报文由状态行、相应头部、空行和响应数据这四个部分组成
⑤浏览器解析HTML代码，并请求HTML代码中的资源
浏览器解析HTML代码
⑥关闭TCP连接，浏览器对页面进行渲染呈现给用户
TCP四次挥手
TCP三次握手：
过程：
一开始客户端为close状态，服务端为listen状态
1.客户端发给服务器：
发送SYN报文，初始序列号ISN，此时处于SYN-sent状态
SYN = 1 ，seq = i （不携带数据，但是消耗一个序列号）
2.服务端发给客户端：
发送SYN+ACK报文，处于SYN-RCVD状态
ACK报文是为了回复客户端的SYN请求报文（客户端序列号+1）
SYN报文是将自己的初始序列号ISN
ACK=1，ack确认序列 = i+1， SYN=1，seq=j（不携带数据）
3.客户端发给服务端：
发送ACK报文，将服务器发送的序列号+1，处与ESTABLESHED状态
ACK=1，ack确认序列 = j+1（可携带数据，不携带则不消化序列号）
为什么是三次握手，四次挥手？
TCP三次握手的时候，接收端将SYN包和ACK确认包合并到一个包中发送的，所以减少了一次包的发送。
对于四次挥手，可能服务器/客户端有一方仍然需要传输数据，需要保持TCP连接，所以需要先回复ACK报文，然后再继续传输数据
为什么握手是三次，而不是两次或者四次？
两次不安全，四次没必要。
第一次握手是客户端发送SYN，服务端接收，服务端得出客户端的发送能力和服务端的接收能力都正常
第二次握手是服务端发送SYN+ACK，客户端接收，客户端得出客户端发送接收能力正常，服务端发送接收能力也都正常，但是此时服务器并不能确认客户端的接收能力是否正常
第三次握手客户端发送ACK，服务器接收，服务端才能得出客户端发送接收能力正常，服务端自己发送接收能力也都正常
三次握手可以携带数据吗？
第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。
假设第一次可以携带数据，如果有人恶意攻击服务器，每次都在第一次握手中的SYN报文放入大量数据，重复发送大量SYN报文，此时服务器会花费大量内存空间来缓冲这些报文，服务器就更容易被攻击了
tcp三次握手失败，服务端会如何处理?
1.服务端没有收到SYN，则什么都不做（没有第一次握手）
2.服务端回复了SYN+ACK后，长时间没有收到ACK响应，则超时后就会发送RST重置连接报文，释放资源（没有第三次握手）
ISN代表什么？意义何在？ISN是固定不变的吗？ISN为何要动态随机
ISN初始化序列号
ISN如果是固定的，攻击者很容易猜出后序的确认号
为了安全起见，ISN是动态生成
什么是半连接队列：
服务器第一次收到客户端的SYN之后，就会处于SYN_RECD状态，此时双方还没有完全建立连接。服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。
当然还有一个全连接队列，就是已经完成三次握手，建立起来连接的就会放在全连接队列中，如果队列满了就有可能出现丢包现象
TCP四次挥手：
过程：
一开始客户端和服务端为ESTABLESHED状态
1.客户端发给服务器：
发送FIN报文，指定序列号，此时客户端处于FIN-wait状态
FIN = 1 ，seq = a
2.服务器回复客户端：（此时可能服务器还有数据没有传完）
发送ACK报文，确认序列号为a+1，此时服务器处于close-wait状态
ACK = 1 ，ack确认序列 = a+ 1 , seq = b
此时客户端收到服务器发来的ACK报文，此时客户端进入FIN-wait2状态
3.服务器发送给客户端：（此时服务器数据传输完成）
发送连续报文FIN+ACK，确认序列号为a+1，序列号为b，服务器进入Last-ACK状态
FIN = 1 ，seq = b ，ACK =1 ， ack确认序列 = a+1
4.客户端回复服务器：
回复ACK报文，表示确认收到，确认序列为b+1，序列号为a+1，此时进入time-wait状态
ACK = 1 ， seq = a+1 ，ack确认序列 = b+1
此时客户端等待2MSL后，进入close状态
MSL：
最大报文存活时间，
保证这个时间内IP和端口不被使用
为什么TIME_WAIT状态需要经过2MSL才能进入CLOASE状态?
1.客户端的ACK包可能丢包，等待服务器的FIN包后，然后再回复ACK，保证服务器收到（此时为2MSL时间）
2.防止影响新的连接（新的TCP连接不会存在旧的报文请求）
一台主机上出现大量的TIME_WAIT是什么原因？应该如何处理？
TIME_WAIT是主动关闭方出现的，一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接。如爬虫
调整TIME_WAIT的等待时间
一台主机上出现大量的CLOSE_WAIT是什么原因？应该如何处理？
CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态
程序bug，需要加上对应的close即可解决问题
HTTP的请求报头：
HTTP的请求报文由请求行、请求头部、空行和请求数据组成
请求行***：
由：请求方法、请求地址URL和HTTP协议版本构成
请求头部：
请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔
HTTP的响应报头：
HTTP响应报文由状态行、相应头部、空行和响应数据组成
状态码***：
1xx 接受的请求正在处理
2xx 请求正常处理完毕
3xx 资源重定向
4xx 客户端请求问题
5xx 服务器处理问题
200 ：表示从客户端发送给服务器的请求被正常处理并返回
301 ：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302 ：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）
303 ：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
302与303的区别：后者明确表示客户端应当采用GET方式获取资源
304 ：表示客户端发送附带条件的请求时，服务器端允许访问资源
400 ：表示请求报文中存在语法错误；
401 ：需要认证
403 ：服务器拒绝该次访问（访问权限出现问题）
404 ：表示服务器上无法找到请求的资源
500 ：表示服务器在执行请求时发生了错误
503 ：表示服务器暂时无法处理请求
响应头部***：
HTTP版本区别：
HTTP1.0和HTTP1.1的区别：
长连接，节约带宽，HOST域，缓存处理，错误通知的管理
长连接：在一个TCP连接上可以传送多个HTTP请求和响应
HTTP1.1和HTTP2.0的区别：
多路复用，头部数据压缩，服务器推送
多路复用：同一个连接并发处理多个请求
头数据压缩：HTTP2.0使用HPACK算法对header的数据进行压缩
Cookie和session还有token：
cookie：本地记录用户状态信息（保存在客户端）
session：服务器用来记录用户状态信息（保存在服务端）
缺点：
cookie保存在浏览器，不安全，数据量少，可被禁用
session寄生在cookie下，对服务器压力大
DNS解析：
递归+迭代查询
递归（浏览器缓存 - 操作系统缓存 - host映射 - DNS缓存）
迭代（顶级域名服务器 - 根域名服务器 - 次级服务器 - 二级服务器）
有就返回，没有则解析不了
SSL加密（HTTPS）：
https和http的区别：
HTTPS是HTTP+SSL+TCP
SSL协议：
①SSL记录协议 ：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。
②SSL握手协议：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL加密过程：（四次握手）
1.客户端发给服务器：clienthello包
携带①客户端支持的协议版本号②客户端支持的加密算法 ③客户端本地产生随机数A
2.服务端回复客户端：serverhello包
携带①协商好的协议版本②协商好的加密算法③服务器证书AC④服务器产生随机数B
3.客户端在接受服务端发送到数据后：
①首先验证服务器证书AC合法性
②如果不合法，通讯断开；如果合法，则可以从服务器证书中获取到公开的密钥。
③客户端通过证书里面的公钥产生一个对称密钥，
④用服务器公钥进行加密，并加密后的对称密钥传给服务器
⑤用密钥加密一个随机数，发送给服务器
4.服务端接受到客户端发来的对称密钥：
①服务端通过用自己的私钥对客户端发来的对称密钥进行解密
②并使用对称密钥对客户端的随机数进行加密
文章评论