欢迎关注我的个人博客分享一些前端技术、面试题、面试技巧等
同源策略
浏览器有一个很重要的概念————同源策略
同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。
同源是指:域名、协议、端口相同。不同源的客户端脚本(js、ActionScript)在没明确授权的情况下,不能读写对方的资源。
-
http与https下的默认端口可省略http=> 80https=> 443
域名是倒着解析的
.com顶级域名baidu.com(一)二级域名zhidao.baidu.com(二)三级域名www二级域名前缀,表示万维网维护的www.baidu.com属于特殊的三级域名
zhidao.baidu.com属于百度自己维护的网络地址
- com、org、net 属于顶级域名,是在全世界范围内解析的,cn、hk 是在一个地区解析的。
- cn 中国
- .com (商业机构)
- .net (从事互联网服务的机构)
- .org (非盈利性组织)
- .com.cn (国内商业机构)
- .net.cn (国内互联网机构)
- .org.cn (国内非盈利性组织)
如果把 IP 地址比作一间房子,端口就是出入这间房子的门。真正的房子只有几个门,但是一个 IP 地址的端口可以有多个。
浏览网页服务默认的端口号都是 80,因此只需输入网址即可,不用输入":80"
当你在浏览器里输入一个 url 发生了什么
简单归纳
- 浏览器通过 DNS 域名解析到服务 IP(ping www.baidu.com)
- 客户端(浏览器)通过 TCP 协议建立到服务器的 TCP 连接(三次握手)
- 客户端(浏览器)向 web 服务器端(HTTP 服务器)发送 HTTP 协议包,请求服务器里的资源文档
- 服务器向客户端发送 HTTP 协议应答包
- 客户端和服务器断开(四次挥手),客户端开始解释处理 HTML 文档
TCP/UDP(传输层协议)
面向连接的 TCP
可靠,过程复杂
TCP(Transmission Control Protocol,传输控制协议)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接。一个 TCP 连接必须要经过三次"对话"才能建立起来。
面向非连接的 UDP 协议
不可靠,实时(视频,语音通话)
"面向非连接"就是在正式通信前不必与对方先建立连接,不管对方状态就直接发送。与手机短信非常相似:你在发短信时,只需要输入对方手机号就可以。 UDP(User Data Protocol,用户数据报协议)是与 TCP 相对应的协议。它是面向非连接的协议,它不与对方建立连接,而是直接把数据包发送过去。
什么是"三次握手,四次挥手"
TCP 是一种面向连接的单播协议,在发送数据前,通信双方必须在彼此间建立一条"连接"。其实是客户端和服务器的内存里保存一份关于对方的信息,如ip地址、端口号等等。
三次握手
简单描述
- 先客户端发送连接,请求报文
- 服务端连接后回复 ACK 报文,并为这次连接分配资源
- 客户端接收到 ACK 报文后也向服务端发送 ACK 报文,并分配资源
作用:为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。
详细描述三次握手
刚开始客户端处于 closed 的状态,服务端处于 listen 状态
第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序号ISN(c)。此时客户端处于SYN_Send状态,等待服务器的确认。
第二次握手:服务器接收到客户端的 SYN 报文后,会对这个 SYN 报文段进行确认,并将自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(c),同时会把客户端的 ISN+1 作为ACK的值,表示自己已经收到了客户端的 SYN,此时服务器处于SYN_RCVD状态。
第三次握手:客户端收到 SYN 报文之后,回发送一个 ACK 报文,也是一样把服务器的 ISN+1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于ESTABLISHED状态。
服务器收到 ACK 报文后,也处于ESTABLISHED状态,此时,双方建立起了链接,完成 TCP 三次握手。
三次握手的目的
- 为了防止已失效的连接请求报文突然又传送到服务端,因而产生错误
- 为了解决"网络中存在延迟的重复分组"问题
- 指定自己的初始化序列号,为后面的可靠传送做准备
- 如果是 https 协议的话,三次握手这个过程,还会进行数字证书的验证以及加密密钥的生成
- 防止了服务器端的一直等待而浪费资源。
四次挥手
简单描述
- 客户端发送中断连接请求,也就是发送 FIN 报文。
- 服务端发送 ACK
- wait:这个时候客户端进入 FIN_WAIT 状态,继续等待服务端的 FIN 报文
- 当服务端确定数据已发送完成,则向客户端发送 FIN 报文
- 客户端收到 FIN 报文后,发送 ACK 后进入 TIME_WAIT 状态,如果服务端没有收到 ACK 则可以重传,服务端收到 ACK 后,就知道可以断开连接了。客户端等待了 2MSL 后依然没有收到回复,则证明服务端已正常关闭,客户端也关闭连接
详细描述四次挥手
刚开始双方都处于 ESTABLISHED 状态,可以是客户端,也可以是服务器端先发起关闭请求。
第一次挥手:客户端设置发送 FIN 报文,报文中会指定一个序列号。此时客户端进入FIN_WAIT_1状态,这表示客户端没有数据要发送给客户端了。
第二次挥手:服务端收到了客户端发送的 FIN 报文段,向客户端返回一个 ACK 报文段,表明自己接受到了客户端关闭连接的请求,且把客户端的序列号值+1 作为 ACK 报文的序列号值,发送完毕后服务器端进入CLOSE_WAIT状态, 客户端进入FIN_WAIT_2状态,等待服务器端关闭连接。
第三次挥手:如果服务端准备好了也想断开连接,和客户端的第一次挥手一样,发送 FIN 报文,,且指定一个序列号。发送完毕后,服务端进去LAST_ACK状态,等待来自客户端的最后一个 ACK
第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己的 ACK 报文的序列号值,此时客户端处于TIME_WAIT状态,等待可能出现的要求重传的 ACK 包;服务端接收到这个确认包后,关闭连接,进入 CLOSED 状态。客户端等待一段时间(两个最大生命周期,2MSL,2 Maximum Segment Lifetime)之后,没有收到服务端的 ACK,认为服务端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。TCP 的四次挥手就完成了。
为什么客户端发送 ACK 之后不直接关闭
要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失,然后再次发送 ACK 报文。
希望对读完本文的你有帮助、有启发,如果有不足之处,欢迎批评指正交流!
欢迎关注我的个人博客分享一些前端技术、面试题、面试技巧等
辛苦整理良久,还望手动点赞鼓励~
'摘抄'不是单纯的“粘贴->复制”,而是眼到,手到,心到的一字一句敲打下来。
博客声明:所有转载的文章、图片仅用于作者本人收藏学习目的,被要求或认为适当时,将标注署名与来源。若不愿某一作品被转用,请及时通知本站,本站将予以及时删除。