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.服务端接受到客户端发来的对称密钥:
①服务端通过用自己的私钥对客户端发来的对称密钥进行解密
②并使用对称密钥对客户端的随机数进行加密