赞
踩
目录
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
一次握手:客户端发送带有 SYN(SEQ=x) 标志的数据包 -> 服务端,然后客户端进入 SYN_SEND 状态,等待服务器的确认;第一次证明客户端的发送能力正常
二次握手:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态。第二次证明服务器端的接收能力、发送能力正常
三次握手:客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端,然后客户端和服务器端都进入ESTABLISHED 状态,完成 TCP 三次握手。第三次证明客户端的接收能力正常
如果采用两次握手会出现以下情况: 客户端向服务器端发送的请求报文由于网络等原因滞留,未能发送到服务器端,此时连接请求报文失效,客户端会再次向服务器端发送请求报文,之后与服务器端建立连接,当连接释放后,由于网络通畅了,第一次客户端发送的请求报文又突然到达了服务器端,这条请求报文本该失效了,但此时服务器端误认为客户端又发送了一次连接请求,两次握手建立好连接,此时客户端忽略服务器端发来的确认,也不发送数据,造成不必要的错误和网络资源的浪费。
如果采用三次握手的话,就算那条失效的报文发送到服务器端,服务器端确认并向客户端发送报文,但此时客户端不会发出确认,由于客户端没有确认,由于服务器端没有接收到确认,就会知道客户端没有请求连接。
比如客户端主动发起断开请求
第一次挥手:客户端发送一个 FIN(SEQ=x) 标志的数据包->服务端,用来关闭客户端到服务器的数据传送。然后客户端进入 终止等待1(FIN-WAIT-1) 状态。
第二次挥手:服务器收到这个 FIN(SEQ=X) 标志的数据包,它发送一个 ACK (ACK=x+1)标志的数据包->客户端 。然后服务端进入 关闭等待(CLOSE-WAIT) 状态,客户端进入 终止等待2(FIN-WAIT-2) 状态。
第三次挥手:服务端发送一个 FIN (SEQ=y)标志的数据包->客户端,请求关闭连接,然后服务端进入 最后确认(LAST-ACK) 状态。
第四次挥手:客户端发送 ACK (ACK=y+1)标志的数据包->服务端,然后客户端进入超等等待(TIME-WAIT)状态,服务端在收到 ACK (ACK=y+1)标志的数据包后进入 关闭(CLOSE) 状态。此时如果客户端等待 一段时间(2MSL) 后依然没有收到回复,就证明服务端已正常关闭,随后客户端也可以关闭连接了。
客户端需要等待超时时间,这是为了保证对方已经收到ACK包,如果客户端发完ACK包就关闭,一旦ack包丢失,服务端将一直停留在最后确认状态。如果客户端可以等待一段时间,这时服务端因为没有收到ack包,会重发fin包,客户端会响应这个fin包,重发ack包并且刷新超时时间,这就可以保证进行可靠的连接断开。
浏览器访问 www.baidu.com,询问本地 DNS 服务器是否缓存了该网址解析后的 IP 地址。
如果本地 DNS 服务器没有缓存的话,就去 root-servers.net 根服务器查询该网址对应的 IP 地址。
根服务器返回顶级域名服务器的网址 gtld-servers.net,然后本地 DNS 服务器去顶级域名服务器查询该网址对应的 IP 地址。
顶级域名服务器返回 www.baidu.com 主区域服务器的地址,然后本地 DNS 服务器去 www.baidu.com 主区域服务器查询此域名对应的 IP 地址。
本地 DNS 服务器拿到 www.baidu.com 解析后的 IP 地址后,缓存起来以便备查,然后把解析后的 IP 地址返回给浏览器
Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁这个 Session)。
Cookie 一般用来在客户端保存用户信息 比如 ① 我们在 Cookie 中保存已经登录过的用户信息,下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了;② 一般的网站都会有保持登录,也就是说下次你再访问网站的时候就不需要重新登录了,这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中,下次登录的时候只需要根据 Token 值来查找用户
Session 的主要作用就是通过服务端记录用户的状态即可
存储位置:Cookie存储在用户的计算机上,而Session存储在服务器上。
安全性:由于Cookie存储在用户的计算机上,因此可能存在安全风险,例如被篡改或窃取。相比之下,Session存储在服务器上,因此更安全。
会话保持方式:Cookie通过将用户信息存储在浏览器中来保持会话状态,而Session通过在服务器上存储用户信息来保持会话状态。
数据大小:由于Cookie存储在用户的计算机上,因此其数据大小有限制,一般不超过4KB。而Session没有数据大小的限制。
生命周期:Cookie有一定的生命周期,一旦超过设定的生命周期,它将被删除。而Session的生命周期与浏览器会话生命周期相同,即用户关闭浏览器时Session将被删除。
安全性考虑:如果Cookie的时效设置过长,那么就可能存在被攻击者窃取的风险。因为攻击者可能会在一段时间内不断地尝试猜测用户的Session ID等敏感信息,如果Cookie的时效设置过长,那么攻击者就有更多的时间来进行这种攻击。因此,将Cookie的时效设置得较短,可以减少攻击者窃取敏感信息的时间。 会话保持:虽然Cookie可以用来保持用户的会话状态,但是如果Cookie的时效设置过长,那么就会存在一些问题。例如,如果用户在一段时间内没有使用网站,那么用户的会话状态就会一直被保留在服务器上,这就会占用服务器的资源。因此,将Cookie的时效设置得较短,可以使得服务器能够及时释放不再使用的会话状态,从而节省资源。 用户体验:如果Cookie的时效设置过长,那么用户在访问网站时就会一直被提示是否允许网站使用Cookie。这会影响用户的体验,因此将Cookie的时效设置得较短可以减少用户的困扰。
200:成功响应
403:客户端发送的url正确,但是服务端由于某些原因拒绝响应
404:客户端请求的资源不存在
400:其他4开头的状态码不适用时使用400,往往是服务器不理解客户端的请求
500:这是一个通用的服务器错误响应。对于大多数web框架,如果在执行请求处理代码时遇到了异常,它们就发送此响应代码。
505: 当服务器不支持客户端试图使用的HTTP版本时发送此响应代码。
用途:
get 请求用来从服务器获取资源
post 请求用来向服务器提交数据
表单的提交方式:
get 请求直接将表单数据以 name1=value1&name2=value2 的形式拼接到 URL 上(http://www.baidu.com/action?name1=value1&name2=value2),多个参数参数值需要用 & 连接起来并且用 ? 拼接到 action 后面;
post 请求将表单数据放到请求头或者请求的消息体中。
传输数据的大小限制:
get 请求传输的数据受到 URL 长度的限制,而 URL 长度是由浏览器决定的;
post 请求传输数据的大小理论上来说是没有限制的。
参数的编码:
get 请求的参数会在地址栏明文显示,使用 URL 编码的文本格式传递参数;
post 请求使用二进制数据多重编码传递参数。
缓存:
get 请求可以被浏览器缓存被收藏为标签;
post 请求不会被缓存也不能被收藏为标签。
在 HTTP 协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的。
如果从 RFC 规范定义的语义来看:
GET 方法就是安全且幂等的,因为它是「只读」操作,无论操作多少次,服务器上的数据都是安全的,且每次的结果都是相同的。所以,可以对 GET 请求的数据做缓存,这个缓存可以做到浏览器本身上(彻底避免浏览器发请求),也可以做到代理上(如nginx),而且在浏览器中 GET 请求可以保存为书签。
POST 因为是「新增或提交数据」的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以不是幂等的。所以,浏览器一般不会缓存 POST 请求,也不能把 POST 请求保存为书签。
TCP/IP 代表传输控制协议/网际协议,指的是一系列协议族。
HTTP 本身就是一个协议,是从 Web 服务器传输超文本到本地浏览器的传送协议。
Socket 是 TCP/IP 网络的 API ,其实就是一个门面模式,它把复杂的 TCP/IP 协议族隐藏在Socket 接口后面。对用户来说,一组简单的接口就是全部,让 Socket 去组织数据,以符合指定的协议。
综上所述:
需要 IP 协议来连接网络
TCP 是一种允许我们安全传输数据的机制,使用 TCP 协议来传输数据的 HTTP 是 Web 服务器和客户端使用的特殊协议。
HTTP 基于 TCP 协议,所以可以使用 Socket 去建立一个 TCP 连接。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。