首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

分布式架构基石

今日金句

发表于苍穹盛夏

查看:13500回复:135

爱情不需要诺言、协议与条件。

但是网络通信没有协议绝对不行,无规矩不成方圆!

什么是网络协议

协议,网络协议的简称,网络协议是通信计算机双方必须共同遵从的一组约定。如怎么样建立连接、怎么样互相识别等。只有遵守这个约定,计算机之间才能相互通信交流。它的三要素是:语法、语义、时序。

为了使数据在网络上从源到达目的,网络通信的参与方必须遵循相同的规则,这套规则称为协议(protocol),它最终体现为在网络上传输的数据包的格式。

协议往往分成几个层次进行定义,分层定义是为了使某一层协议的改变不影响其他层次的协议。

1

HTTP请求概述

01

HTTP请求过程

应用程序用TCP传送数据时,数据被送入协议栈中,然后逐个通过每一层直到被当作一串比特流送入网络,其中每一层对收到的数据都会增加一些首部信息

02

四层网络概念模型

1 客户端-服务端

2 分用

当目的主机收到一个以太网数据帧时,数据便开始在协议栈中由底向上升,同时去掉各层协议加上的报文首部,每层协议盒都要去检查报文首部中的协议标识,以确定接收数据的上层协议,这个过程称作 分用

3 服务端-客户端

物理层解析比特流 数据通过网卡时解析比特流 看看数据是否需要请进来做做

数据链路层获取MAC头 检查MAC地址是否匹配 如果匹配 则说明当前是发给我的

网络层获取IP头 获取IP头,判断IP地址是不是自己的,如果不是 就转发交给上一层去处理

传输层获取TCP头 带目标端口号 将报文交给指定端口的进程进行处理

如下图(图片不清晰可到后台留言获取)

注意:

IP负责定位发给哪个服务器

MAC用于确认是否是发给我的

4 问题

为什么有了全网唯一的MAC层还需要走IP层呢?

其实,mac地址类似于个人的身份证号码,人的身份证号码和户口所在地、出生日期、性别等相关,但是和人的每时每刻所处的位置并没有关系,人是会移动的,也就是说即使我们知道一个人的身份证号,也无法找到这个人此刻所在的精确地点,也就是不能找到这个人。mac地址是和设备的生产者、批次、出厂日期等相关信息关联的,知道一个设备的mac地址,并不能在众多网络中找到它并把数据发送给它,除非它和网络发送放在同一个网络内。

从而,综上可得,我们要实现机器之间的通信,必须要有IP地址的存在来确定当前机器在网络中的精确位置,类似于省市区街道门牌号的概念。通过IP层的寻址,我们能和全世界任意一台Internet上的机器间传输数据

2

深入分析 TCP/IP 协议

01

概念

TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能。

2

作用

协议能够检测和恢复IP层提供的主机到主机的通信中可能发生的报文丢失、重复及其他错误,提供了一个可信赖的字节流通道,协议是一种面向链接的协议,在使用进行通信之前,两个应用程序之间需要建立一个连接,建立连接的过程则就是我们经常提起的三次握手、四次挥手,因为传送数据之前必须先建立连接,数据传送完成后要释放连接,所以就不可避免的增加了许多的开销,比如确认、流量控制等。对应的应用层的协议主要有接下来将会详细讲解这两个概念。

03

核心知识

01 TCP是如何做到可靠传输的?

是一种可信的传输协议,所以传输开始之前需要通过三次握手建立一个连接,所谓的三次握手,就是建立连接时,需要客户端和服务端总共发送3个包来确认连接的建立。

02 TCP报文信息概述

源端口和目的端口:各占两个字节,分别写入源端口和目的端口;

序号:占四个字节,TCP连接中传送的字节流中的每个字节都按顺序编号;(例如,一段报文的序号字段值是 201 ,而携带的数据共有100字段,显然下一个报文段(如果还有的话)的数据序号应该从301开始)

确认号:占4个字节,是期望收到对方下一个报文的第一个数据字节的序号;(例如,B收到了A发送过来的报文,其序列号字段是501,而数据长度是200字节,这表明B正确的收到了A发送的到序号700为止的数据。因此,B期望收到A的下一个数据序号是701,于是B在发送给A的确认报文段中把确认号置为701)

数据偏移:占4位,指出报文的数据举例TCP报文段的起始处有多远;

保留:占6位,保留今后使用,目前应都为0;

紧急: 当时,表明紧急指针字段有效,告诉系统此报文段中有紧急数据;

确认: 仅当时 ,确认号字段才有效,规定,在连接建立之后所有报文的传输都必须把置为1;

推送: 当两个应用进程进行交互通信时,有时在一端的应用程序希望在键入一个命令后立即就能收到对方的响应,这是候就将;

复位: 当,表明连接中出现严重差错,必须释放连接,然后再重新建立连接;

同步:在连接建立时用来同步序号,当,表明是连接请求报文,若同意连接,则响应报文中应该使用;

终止: 用来释放连接,当,表明此报文的发送方的数据已经发送完毕,并且要求释放;

窗口: 占2字节,指的是通知接收方,发送本报文你需要多大的空间来接收;

检验和: 占2字节,校验首部和数据这两部分;

紧急指针: 占2字节,指出本报文段中的紧急数据的字节数;

选项: 长度可变,定义一些其他的可选的参数。

03 TCP连接的建立(三次握手)

1.服务器进程先创建传输控制块,时刻准备接收客户进程的连接请求,此时服务器便进入了状态 ;

2.客户进程也是先创建传输控制块,然后向服务器发出连接请求报文,此时报文首部中的同步位,同时选择一个初始序列号,此时,客户短进程进入了状态 。规定,报文段()不能携带数据,但需要消耗掉一个序号。

3.服务器收到请求报文后,如果同意连接,则发出确认报文。确认报文中应该,同时也要为自己初始化一个序列号,此时,服务器进程进入了状态 ,这个报文也不能携带数据,但是同样需要携带一个序号。

4.客户进程收到确认后,还要向服务器给出确认。确认报文的,此时,连接建立,客户端进入状态,规定,报文段可以携带数据,但是如果不携带数据则不消耗序号。

当服务端接收到客户端的确认后也进入状态,此后双方便开始通信。

如图所示(需要高清图可后台留言获取)

04 三次握手中为什么TCP客户端最后还要发送一次确认呢?

目的在于防止已经实效的连接请求报文突然又传送到了服务器,从而产生错误。

如果不存在第三次确认报文,假设客户端发送了第一个请求连接并且没有丢失,但是因为在网络节点中发生了滞留,由于迟迟没有收到确认报文,以为服务器没收到,此时会重新向服务器发送这条报文,此后客户端和服务端经过两次握手完成连接,传输数据,关闭连接。此时此前滞留的哪一次请求连接,网络通畅了到达了服务器,这个报文本该是报销的,但是 两次握手机制会让客户端和服务器再次建立连接,这将导致不必要的错误的资源的浪费。如果使用的是三次握手,就算本次失效的报文传送过来,服务端接收到实效报文并且回复了确认报文,但是客户端不会再次不会发审却惹,有于服务器收不到确认,就知道客户端并没有请求连接。

05 TCP关闭连接的过程(四次挥手)

客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,,其序列号为,此时,客户端进入状态。规定,报文段即使不携带数据,也要消耗一个序号。

服务器收到连接释放报文,发出确认报文,,此时,服务端就进入了。服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个状态持续的时间。

客户端收到服务器的确认请求后,此时,客户端就进入状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。

服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了,等待客户端的确认。

客户端收到服务器的连接释放报文后,必须发出确认,,此时,客户端就进入了状态。注意此时连接还没有释放,必须经过后,当客户端撤销相应的后,才进入。

服务器只要收到了客户端发出的确认,立即进入。同样,撤销后,就结束了这次的连接。可以看到,服务器结束连接的时间要比客户端早一些。

如图所示(需要高清图可后台留言获取)

以上过程如果不考虑具体的标记状态的话可以用以下过程形容:

挥手过程:

client : 我要走了

server : 好 我知道了 先等我一下

server : 我好了 你走吧

client : 好的

6 关闭连接过程中为什么客户端最后还要等待 2MSL ?

: 意思是多层交换(),指的是交换机能通过硬件来交换和路由选择数据包,并可能通过硬件支持4~7层交换。通过硬件进行交换和路由时,即使所有的端口同时发送信息流,吞吐量也可达到或接近线速。

允许不同的实现可以设置不同的值,这样做的目的在于

1.保证客户端发送的最后一个报文能够到达服务器,因为这个报文可能丢失,站在服务器的角度看来,我已经发送了报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个内收到这个重传的报文,接着给出回应报文,并且会重启;

2.防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,这样新的连接中不会出现旧连接的请求报文。

3

为什么建立连接是三次握手,关闭连接是四次挥手呢?

建立连接的时候,服务器都是在LISTEN 状态下,收到建立连接请求的SYN报文后,把 ACK 和 SYN 放在一个报文里发送给客户端,其中ACK 报文是用来应答的,SYN报文是用来同步的 ;

关闭连接时。服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接受数据,而自己也未必把全部数据都已经发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN 报文给对方表示同意后才关闭连接,也就是说不会马上关闭socket ,因此,ACK 和 SYN 报文一般都会分开发送,先发送FIN报文告诉客户端”你发的报文我收到了“,但是只有在服务端所有报文都发送完毕之后才能发送FIN报文,因此不能一起发送,从而导致多了一次。

注意:

客户端和服务端均可主动发起挥手动作(TCP是一个全双工协议),在socket编程中,任何一方执行 close() 操作即可产生挥手操作

4

TCP流量整形

01

数据传输过程的流量控制和确认机制

可靠连接建立之后便开始数据传输,在通信过程中,如果数据的传送和接收过程中出现了接收方来不及接收数据包的情况,此时就需要对发送方进行控制以免数据丢失。利用滑动窗口机制 可以很方便的在TCP连接上实现对发送方的流量控制,TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值。

02

滑动窗口协议

滑动窗口协议(Sliding Window Protocol),属于TCP协议的一种应用,用于网络数据传输时的流量控制,以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,提高网络吞吐量。

是一种流量控制技术,发送方和接收方都会维护一个数据帧的序列,这个序列被称作窗口。发送方的窗口大小由接收方确定,目的在于控制发送速度,以免接收方的缓存放不够大,而导致溢出,同时控制流量也可以避免网络阻塞。

如下图:

4 5 6 号数据帧已经被发送出去,但是未收到关联的ACK,7 8 9号数据帧则是等待发送,可以看到发送端的窗口大小是6(由接收端告知的),此时如果发送方接收到4号ACK,则窗口的左边缘向右收缩,窗口的右边缘向右扩展,此时窗口便向前滑动,所以9 之后的数据帧也可以被发送。

03

发送窗口

发送窗口是发送方已发送但尚未被确认的帧的序号队列的界限,其上下界分别为窗口的上下沿,上下沿的距离为窗口尺寸。

简而言之,就是发送段允许连续发送的帧的序号表,发送方可以不等待应答而连续发送的最大帧数称为发送窗口的尺寸。

4

接收窗口

接收方允许接收的帧的序号表,凡是落在接收窗口内的数据帧,接收方都必须处理,落在接收窗口外的数据帧都被丢弃。接收方每次允许接收的帧数称之为接收窗口的尺寸。

转载是一种动力 分享是一种美德

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180923G0VIQE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券