非常详细的讲解在浏览器中输入bilibili.com后执行的全部过程,可结合我前面说的TCP协议食用

  • 首先在我们发送消息的时候浏览器会返回我们一个状态码200-300之间表示一切正常,300-400的状态码代表转向到其他地方,400-500之间代表你的错,500-600代表网站的错误这些我们都可以通过F12去进行查看

  • 我们在点击F12中捕获的链接的时候我们可以看到时间线的变化,整个时间线讲述了我们按下回车之后浏览器干的所有事情的时间

    时间线以4种颜色区分网站打开过程中的每个阶段

    • 红色:初始链接阶段可能因为太快而看不到(瞬间)
    • 紫色:SSL加密协议密钥的阶段
    • 绿色:服务器准备内容的阶段
    • 蓝色:下载内容的阶段
  • 域名组成:从http//或者https://的斜杠开始代表我要访问网址首页比如https:www.bilibili.com ,如果com后面还有斜杠+其他数组和字母的话那么表示网站的其他路径。比如www.bilibili.com//tv表示我要访问哔哩哔哩的电视剧部分

    域名的主题部分就相当于我们存储在通信录中的人名,每个联系人对应的都有自己的电话号码,域名也是一样的它对应着有相应的服务器IP这样任何人访问哔哩哔哩就可以知道去那个服务器里要我们想要的东西。

  • 通常我们验证是否可以于服务器进行交互就采用ping的方式来进行

    PS C:\Users\yaojing> ping bilibili.com
    
    正在 Ping bilibili.com [120.92.78.97] 具有 32 字节的数据:
    来自 120.92.78.97 的回复: 字节=32 时间=7ms TTL=54
    来自 120.92.78.97 的回复: 字节=32 时间=7ms TTL=54
    来自 120.92.78.97 的回复: 字节=32 时间=7ms TTL=54
    来自 120.92.78.97 的回复: 字节=32 时间=6ms TTL=54
    
    120.92.78.97 的 Ping 统计信息:
        数据包: 已发送 = 4,已接收 = 4,丢失 = 0 (0% 丢失),
    往返行程的估计时间(以毫秒为单位):
        最短 = 6ms,最长 = 7ms,平均 = 6ms
    

    除非服务器禁ping如果不超时就证明我们可以与服务器建立链接,ping的域名后方出现了[120.92.78.97]它就是哔哩哔哩服务器的IP地址,输入网址按上回车第一件事情就是去找域名所对应的服务器地址。

  • 那么问题来了这个IP是从哪里来的,他是从DNS存储的地址本中找到的如果访问过哔哩哔哩那么就从本机缓存的数据中去找如果找不到就从路由器设置的电信服务器商提供的DNS服务器中去找如果还是找不到就从网站域名服务商提供的DNS服务器中去找所以DNS域名服务器是分布式存储的

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VOWPWo0A-1677246793908)(assets/image-20230223022307407.png)]

  • 我们可以通过nslookup命令验证如何从DNS查询域名对应的IP

    PS C:\Users\yaojing> nslookup
    默认服务器:  UnKnown
    Address:  fe80::1
    
    > bilibili.com
    服务器:  UnKnown
    Address:  fe80::1
    
    非权威应答:
    名称:    bilibili.com
    Addresses:  8.134.50.24
              47.103.24.173
              119.3.70.188
              120.92.78.97
              139.159.241.37
    

    我们看到哔哩哔哩相应的5个地址,很有可能是因为哔哩哔哩流量过大,然后使用了CDN技术做了资源加速,让从最近的服务器中去读取资源,我们可以将DNS服务器设置为8.8.8.8

    > server 8.8.8.8
    默认服务器:  dns.google
    Address:  8.8.8.8
    
    > bilibili.com
    服务器:  dns.google
    Address:  8.8.8.8
    
    非权威应答:
    名称:    bilibili.com
    Addresses:  120.92.78.97
              139.159.241.37
              8.134.50.24
              47.103.24.173
              119.3.70.188
    

    我们可以看到哔哩哔哩的相应结果是一致的,域名的绑定操作肯定是哔哩哔哩所属公司绑定的,他们注册了哔哩哔哩的域名,然后指定好域名的DNS做好A记录解析来对应好服务器的IP地址,这样就可以通过域名访问IP了

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b2NW65UP-1677246793910)(assets/image-20230223022946000.png)]

  • 我们可以通过使用whois bilibili.com去看一看域名的注册信息

    
    
  • HTTPS超文本传输协议

    其中HTTPS代表他是加密传输的用来保证传输的安全性,服务器和运行商之间的协商就对应着开头讲的紫色部分,地址栏有小锁图标代表信任的安全认证的加密证书,点开之后我们可以看到证书的使用人和颁发人,证书的有效时间、指纹信息,传输内容的加密是非对称加密,服务器持有密钥客户端持有公钥,我们可以在详细信息中可以看到证书的签名算法、公钥的路径等等,我们发现HTTPS加密传输每次都要协商时间说明比HTTP非加密访问要慢,但是现在浏览器如果不使用HTTPS的话会出现不安全的提示。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ORUGhX6S-1677246793910)(assets/image-20230223023823242.png)]

    我们采用curl来模拟访问HTTPS可以明显的看到协商密钥交互有握手的部分,协商成功之后将使用TSL(证书)进行加密连接,使用HTTP2的协议进行传输

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5DcPHrfT-1677246793911)(assets/image-20230223024338229.png)]

  • OSI7层模型

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-87ZkdZY0-1677246793911)(assets/image-20230223024706840.png)]

    我们按按照客户端数据流向的方向从最高层开始说明,

    第7层是由应用程序负责的协议层,例如HTTP协议、SMTP协议、POP协议等,

    第六层表示数据的加密、解密等比如HTTP传输的gzip数据压缩缩小数据的大小用来节约网络传输数据的流量,第五层会话层就是上面所说的紫色部分负责的就是数据加密协议的协商工作,

    5、6、7可以统称为应用程序层,在数据向下传输的阶段,在数据断前加入HTTP标头,比如请求的方法是set还是get等信息,

    第四层就是经典传输层比如TCP协议和UDP协议,比如TCP会为数据段添加20字节的的表头,比如源端口,目标端口,请求序列号等,网络层中典型的IPV4和IPV6就出现在这一层会为数据段追加来源IP和目标IP,路由选择一般是就近原则进行选择,我们可以使用下面的命令模拟一下路由选择,下一跳的次数越多证明经停站就越多到达目的地是时间就越长

    最多跟踪10个跃点,从本机到bilibili.com的网络路由跟踪。它可以帮助检查网络中的故障点,并帮助确定网络延迟的原因。
    Linux/Mac:使用 traceroute -m 10 bilibili.com 
    Windos:tracert -h 10 bilibili.com
    下面是我的的数据
      1     1 ms     1 ms     1 ms  192.168.1.1
      2     4 ms     4 ms     4 ms  10.70.0.1
      3     *        *        *     请求超时。
      4     *        *        *     请求超时。
      5     *        *        *     请求超时。
      6    40 ms    39 ms    39 ms  112.89.0.142
      7    40 ms    45 ms    40 ms  120.80.137.90
      8    42 ms    41 ms    42 ms  157.148.24.42
      9     *        *        *     请求超时。
     10     *        *        *     请求超时。
    

    这也是为什么哔哩哔哩我们在前面使用NSlookup查找域名的时候会有多个IP,是因为哔哩哔哩为了让用户更快的访问网页使用了CDN技术让我们可以在离我们最近的服务器中快速的打开网站。当数据经历过

    第二层的数据链路层的时候加入MAC地址(每个网卡唯一)再由物理层传输过去,

    物理层接受然后再逐个拆包到应用层就拿到了真正的数据啦。

    那么现在我们已经相互可以连接了但是为了保证我们连接的通畅,他们还要建立可靠的链接通畅所有加入三次握手和四次挥手,

    image-20230224203556396

    正常的三次握手发生在上面请求所说的红色阶段也就是初始链接阶段,

    第一次握手是客户端带上序列号x给服务器打招呼,这时候客户端进入SYN—SENT同步发送状态,

    第二次握手服务器监听相关的端口,比如80端口或者443端口,服务器监听端口收到了消息之后带上了的自己的序列号Y并且带上ACK确认码为客户端带来的序列号+1然后回复服务器进入SYN—RCVD的同步已回复状态,

    第三次握手客户端收到了服务器的回复带上服务器回复的序列号+1的确认码发送给服务器,建立链接成功

    ​ 比如A给B打电话,A说“喂你好”,B这时候知道A能说话,有声音但是A,不知道B能不能听到A自己的声音。

    然后B也回复一个“你好啊”,这时候A知道自己的声音发送出去了,自己也能听到B的声音,但是B不知到自己的声音对方能听到不

    然后A回复“我有点事情想说”,这时候B知道自己的声音A知道了,自己也能听到A的声音

    三次握手失败的情况:

    握手第一次找服务器失败会从1秒开始,每次两倍的方式试5次,默认一分钟没收到服务器回复,就报错了!

    第二次握手失败,服务器同样会重试5次。但有意思的是客户端和服务器都会在这次重试,成功率会高。

    第三次失败,同上,不要超过服务器的重试次数,客户端要保证尽快同步确认。

  • image-20230224211214736

    四次挥手是当客户端打算关闭链接时会主动带上,挥手的时候客户端确认码作为序列号发送给服务器断开链接,客户端进入结束等待1就是FIN—WAIT—1的状态,服务器端收到客户端的分手消息会带上自己的序列号V既客户端带来的序列号+1作为确认码回复给客户端,客户端表示分手的消息我收到了我再想想,这时候服务器端进入CLOSE-WAIT等待关闭状态,客户端进入继续等待IN—WAIT—2的状态发生了

    第二次挥手,服务器想了想没有更多的话要对客户端说了于是带上序列号W和序列号+1的确认码,给客户端发送分手请求,没啥想要说的了分手就分手吧,然后服务器进入LAST-ACK最好确认状态发生了

    三次挥手,客户端收到了分手的请求之后带上+1的序列号和+1的确认码回复给路由器于是服务器关闭了链接,客户端进入定时等待时间-2个报文的最大生产周期时间冷静期后客户端才真正的断开。

    如果失败的话:

    • 如果第一次挥手,客户端同样重试超时的话,客户端会直接关闭连接。
    • 第二次挥手是服务器回复,不回复就参考1。但是服务器端回复了,客户端收到后,就不试了,会等服务器第三次挥手,默认是不超过60秒,否则客户端直接关闭。
    • 第三次挥手同样重试机制,主动权在服务器而已,就是视频中的最后等待状态。
    • 第四次挥手参考3的服务器重试,如果客户端回复确认成功

    总结:

  1. 域名解析(域名 www.baidu.com 变为 ip 地址)–DNS查找域名对应的IP地址。
    浏览器搜索自己的DNS缓存(维护一张域名与IP的对应表);若没有,则搜索操作系统的DNS缓存(维护一张域名与IP的对应表);若没有,则搜索操作系统的hosts文件(维护一张域名与IP的对应表)。
    若都没有,则找 tcp/ip 参数中设置的首选 dns 服务器,即本地 dns 服务器(递归查询),本地域名服务器查询自己的dns缓存,如果没有,则进行迭代查询去询问根域名服务器如果根域名服务器也没有那么去COM顶级域名服务器去查询,COM顶级域名服务器有记录这个域名在哪,然后就找到这个服务器的ip。将本地dns服务器将IP返回给操作系统,同时缓存IP。
  2. 发起 tcp 的三次握手,建立 tcp 连接。浏览器会以一个随机端口(1024-65535)向服务端的 web程序 80 端口发起 tcp 的连接。–三次握手进入初始化连接(每次都会重走7层协议)
  3. 建立 tcp 连接后发起 http 请求–如果是HTTPS协议那么回进入SSL加密协议协商握手。
  4. 服务器响应 http 请求,客户端得到 html 代码–服务器应该准备内容、客户端下载内容阶段。
  5. 服务器 web 应用程序收到 http 请求后,就开始处理请求,假设是tomcat的情况下,服务器端socket接受到HTTP信息,并且处理字符串,拿到请求的路径,用请求的路径去存放了Servlet的HashMap中去寻找,如果找不到那么去,静态资源中寻找,如果找到了处理之后就返回给浏览器 html 文件。
  6. 用的也是HTTP协议进行的回传,将文件进行一个分包,并且发送,将每个报文段都可靠的发送给对方,到客户端按照报文段中的顺序进行组装这样就得到了接受的数据
  7. 浏览器解析 html 代码,并请求 html 中的资源。
  8. 浏览器对页面进行渲染,并呈现给用户。

本教程借鉴于https://www.bilibili.com/video/BV1j24y1v7gp?t=710.0有兴趣可以去看看

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值