关于网络编程:网络是怎么样连接的读书笔记-WEB服务端请求和响应五

36次阅读

共计 3081 个字符,预计需要花费 8 分钟才能阅读完成。

《网络是怎么样连贯的》读书笔记 – WEB 服务端申请和响应(五)

本章重点

客户端和服务端的区别 以及客户端响应的连贯过程。

客户端和服务端的区别

服务器的分类和性能品种有很多,然而网络相干的局部,如网卡、协定栈、Socket 库等性能和客户端却并无二致。

另外咱们能够回顾第一章笔记中介绍了对于互联网的历史局部,网络自诞生开始就是为了军事通信,意味着最好是在数据收发层面不须要辨别客户端和服务器,而是可能以左右对称的形式自在发送数据。所以咱们常说的客户端和服务端仅仅是从发送者和接受者的角度来辨别,如果服务器发送申请到客户端,也能够认为服务器自身是“客户端”。

对于服务端和客户端咱们从 Socket 库调用上查看两者差异:

客户端的数据收发须要 通过上面 4 个阶段。

(1)创立套接字(创立套接字阶段)

(2)用管道连贯服务器端的套接字(连贯阶段)

(3)收发数据(收发阶段)

(4)断开管道并删除套接字(断开阶段)

服务器是将阶段(2)改成了 期待连贯

(1)创立套接字(创立套接字阶段)

(2-1)将套接字设置为期待连贯状态(期待连贯阶段)

(2-2)承受连贯(承受连贯阶段)

(3)收发数据(收发阶段)

(4)断开管道并删除套接字(断开阶段)

连贯过程

上面和第二章介绍客户端连贯相似,介绍服务端连贯的步骤。

首先调用 bind 将端口号写入套接字中,并且要设置端口,之后协定栈会调用 accept 连贯,留神这时候包可能是没有到来的,如果包没有到来服务端会阻塞期待客户端的申请,一旦接管到连贯就会开始响应并且进行连贯操作。

接下来协定栈会给期待连贯的套接字复制一个正本,而后将连贯对象等管制信息写入新的套接字中,为什么这里要创立正本简略解释一下,因为如果间接应用原有的套接字连贯,那么当新的客户端申请过去,就必须要再次创立新的套接字而后再次进行连贯。应用复制套接字的形式,原有的套接字仍然能够实现期待连贯的工作,和新建的套接字正本是没有关联的。

创立套接字除了复制套接字这个特点外,还有一个是端口号的应用,因为一个套接字须要对应一个端口号,然而须要留神新创建的套接字正本必须和原来的期待连贯的套接字具备雷同的端口号,起因是避免相似客户端原本想要连贯 80 端口上的套接字,后果从另一个端口号返回了包这样的状况。

针对这个问题,服务端的套接字除了确定端口之外,还须要带上 IP 信息和客户端的端口号信息,最终依附上面四个变量来确定和哪一个套接字交互。

  • 客户端 IP 地址
  • 客户端端口号
  • 服务器 IP 地址
  • 服务器端口号

从下面这幅图能够看到,服务端可能会在一个端口上创立正本绑定很多个套接字,然而客户端的端口是齐全不同并且随机的,同时 IP 地址也不一样,所以能够确定套接字之间是不会存在抵触的。

套接字筹备实现之后,接着是对于网络包进行 FCS 的校验,当 FCS 统一确认数据没有谬误时,接下来须要查看 MAC 头部中 的接管方 MAC 地址,看看这个包是不是发给本人的,之后网卡的 MAC 模块将网络包从信号还原为数字信息,校验 FCS 并存入缓冲区。

网卡收到音讯之后,接着是执行中断解决机制告知 CPU 开始进行网卡的数据处理,对于中断解决的内容能够通过的另一本书《Linux 是怎么样工作的》理解 CPU 的中断解决机制理解整个执行过程,之后网卡驱动会依据 MAC 头部判断协定类型,并将包交给相应的协定栈。

为什么还要应用描述符呢?

这里回顾一下描述符的内容,描述符指的是在创立套接字之后,服务端须要返回给客户端一条标识信息,目标是告知客户端本人是谁,协定栈 也须要返回 描述符 用于标识是哪一个套接字在进行传数据。

这里能够简略了解为咱们在网络聊天的时候尽管晓得对方是谁和本人聊天,然而如果对方没有“开摄像头”通知你我是自己,很有可能是他人假装你意识的人在和你聊天。而咱们晓得对方是自己在和咱们聊天也是因为对方的一些“性情”所以理解。

当网络包转交到协定栈时,IP 模块会首先开始工作查看 IP 头部。IP 头部次要是查看标准,查看单方的 IP 地址,确认包是不是发给本人的,确认包是发给本人的之后,接下来须要查看包有没有被分片,而后查看 IP 头部的协定号字段,并将包转交给相应的模块。

IP 模块接管操作小结

协定栈的 IP 模块会查看 IP 头部:

(1)判断是不是发给本人的;

(2)判断网络包是否通过分片;

(3)将包转交给 TCP 模块或 UDP 模块。

依据 IP 头部的协定找到 06 发现是 TCP 协定判断之后的内容是 TCP 模块的包,此时查看管制位 SYN 是否为 1,这也示意这是一个发动连贯的包。

TCP 模块会执行承受连贯的操作,此时须要同时查看端口是否存在对应的套接字连贯,如果没有则会向客户端返回谬误告诉的包,如果存在则复制套接字的正本,并且单方须要互相交换信息存储在套接字的缓冲区,这时候服务器端的程序应该进入调用 accept 的暂停状态,当新套接字的描述符转交给服务器程序之后,服务器程序就会复原运行。

接下来是 TCP 模块解决数据局部,首先是查看收到的包对应哪一个套接字,这里对应之前说的四种信息判断惟一套接字,因为服务端的一个端口可能绑定十分多的客户端端口。

对上套接字之后,TCP 模块会比照该套接字中保留的数据收发状态和收到的包的 TCP 头部中的信息是否匹配,比方查看收到的包序号是否匹配等,如果数据确认无误,将会生成对应的应答头部并且计算 ACK 号码,而后本人再生成一个序号返回给客户端。

收到的数据块进入接收缓冲区,意味着数据包接管的操作告一段落了,之后传递数据会通过 read 期待而后间接交给利用程序处理了,最初应用程序依据申请的内容向浏览器返回相应的数据。

TCP 模块操作小结

(1)依据收到的包的发送方 IP 地址、发送方端口号、接管方 IP 地址、接管方端口号找到绝对应的套接字;

(2)将数据块拼合起来并保留在接收缓冲区中;

(3)向客户端返回 ACK。

最初是断开操作,断开操作的次要区别在 HTTP 协定上,HTTP1.0 须要服务器发动,而 HTTP1.1 当中断开由客户端开始。

为什么 HTTP1.0 和 HTTP1.1 在断开的时候有如此差异,能够看上面的补充内容,这部分内容来自网络:

http1.0

  • 如果在 HTTP 申请中携带 content-length,此时申请 body 长度可知,客户端在接管 body 时就能够根据这个长度来承受数据。承受结束后,就示意这个申请结束了。客户端被动调用 close 进入四次挥手。
  • 反之,如果不带 content-length,则 body 长度不可知,客户端始终承受数据,直到服务端被动断开。

http1.1

  • 如果 HTTP 申请中携带 content-length,此时 body 长度可知,则由客户端被动断开。
  • 如果发现 HTTP 中带 Transfer-encoding:chunked body 会被分成多个块,每块的开始会标识出以后块的长度,body 就不须要通过 content-length 来指定了,但仍然能够晓得 body 的长度,此时客户端被动断开。
  • 如果申请不带不带 Transfer-encoding:chunked 且不带 content-length,客户端接收数据,直到服务端被动断开连接。

也就是说如果可能 有方法晓得服务器传来的长度,都是客户端首先断开。如果不晓得就始终接收数据直到服务端断开。

总结

这一章节的内容更像是对于后面几章内容的查漏补缺,以及对于之前内容做了一整体的简略温习,在后半局部介绍了对于应用程序返回数据的介绍,这部分比拟偏差 WEB 所以就没有收录到笔记当中了。

整体看下来这本书须要重点学习的是后面的三章内容,前面两章内容更像是理论知识的补充以及对于后面内容的补充。

对于最初一章服务端响应数据的细节倡议和客户端联合学习,成果会事倍功半。

正文完
 0