浏览器输入地址后发生了什么?TCP/IP是什么?

推荐一个动画:https://www.bilibili.com/video/BV18x411Y79e

本文是浅解。

总结:在谷歌浏览器输入www.baidu.com,谷歌浏览器交给域名解析系统(Domain Name Systrem)进行字母到IP地址的解析,解析的过程中会经过路由器,路由器的作用是通过子网子网指挥下一步应该往哪条路走可以找到你的IP,(那么面对路由器的时候也需要有IP啊,这个IP不是baidu,而是DNS的IP,如8.8.8.8),直到根据DNS的IP找到DNS域名解析服务器,DNS会告诉你baidu这个字母(白盒子)对应的IP(黑盒子)是多少,然后拿着这个IP去这个IP服务器请求对应的页面。请求的页面中也是拿着百度的IP经过路由器的时候根据子网掩码选择走哪条路,最终走到百度的服务器,百度的服务器把页面如<head>这些内容返回来给浏览器,浏览器根据编程语言转换为可视化页面。

  • baidu到IP的解析过程中不一定非得去DNS服务器查的,因为浏览器中有一些字母到IP键值对的缓存,系统的/etc/hosts下也有一些键值对,然后才去服务器去查。
  • 拿到字母对应的IP后,通过TCP连接(三次握手)

理解三次握手四次挥手的核心在于要理解“收到信息要回复收到”

客户端 服务端 SYN=1,seq=n, SYN=1,seq=x,ACK=1,ack=n, SYN=0,seq=x+1,ACK=1,ack=x+1, 客户端 服务端
  • 连接后发生HTTP请求
  • 服务器处理请求,返回HTTP报文
  • 浏览器解析和渲染页面
  • 四次挥手断开连接
客户端 服务端 FIN=1,seq=x seq=y,ACK=1,ack=x, FIN=1,seq=y+1, seq=x+1,ACK=1,ack=y+1, 客户端 服务端

问题:我们用的AJAX会重新建立连接吗?还是用原来的TCP连接?

在同一个页面中,请求比较多的话,可以打开HTTP KeepAlive, 复用连接,避免3次握手带来的开销。
HTTP2.0 进一步优化,通过多路复用技术,允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。也就是可以在在一次传输中发送多个css,js,图片等资源。

保持socket连接

补充TCP/IP

  • TCP:可靠连接,双向传输
  • UDP:不可靠连接,单向传输

协议

  • 应用层:HTTP/FTP
  • 传输层:TCP/IP
  • 网络层 ARP/RARP
  • 数据链路层

640?wx_fmt=png

640?wx_fmt=png

TCP报文:

在这里插入图片描述

img

640?wx_fmt=png

IP报文:

img

数据链路层:

数据链路层的工作特性:

  • 为IP模块发送和接收IP数据报
  • 为ARP模块发送ARP请求和接收ARP应答(ARP:地址解析协议,将IP地址转换成MAC地址)
  • 为RARP发送RARP请求和接收RARP应答

接下来我们了解一下TCP/IP的工作流程:
数据链路层从ARP得到数据的传递信息,再从IP得到具体的数据信息

下面内容来源于网络转载:

经典问题:

为什么要等待2MSL?

MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。
原因有二:

  • 保证TCP协议的全双工连接能够可靠关闭
  • 保证这次连接的重复数据段从网络中消失

第一点:如果主机1直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN,此时由于主机1已经CLOSED了,就找不到与重发的FIN对应的连接。所以,主机1不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。

第二点:如果主机1直接CLOSED,然后又再向主机2发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达主机2,由于新连接和老连接的端口号是一样的,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。

TCP流量控制:

如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

设A向B发送数据。在连接建立时,B告诉了A:“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此,发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意,TCP的窗口单位是字节,不是报文段。假设每一个报文段为100字节长,而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK,小写ack表示确认字段的值ack。

640?wx_fmt=png

从图中可以看出,B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ,第二次又减到了 rwnd = 100 ,最后减到 rwnd = 0 ,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ,只有在ACK=1时确认号字段才有意义。

TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口控测报文段(携1字节的数据),那么收到这个报文段的一方就重新设置持续计时器。

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值