关于javascript:一文让你读懂TCP1

51次阅读

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

前言

上篇咱们讲了 http,咱们晓得了 http 是基于 tcp 的,先来看张图:

http 是应用层协定,tcp 是传输层协定,http 作为下层协定建设在 tcp 之上。当然你看到传输层协定还有一个兄弟叫 udp,这家伙常常和 tcp 做比拟,本篇不做讲述,想晓得的可自行理解吧,好了上面让咱们间接进入注释吧。

tcp

传输控制协议(TCP,Transmission Control Protocol)是一种 面向连贯的、牢靠的、基于字节流的 传输层通信协议

传输就好比是咱们买的快递通过交通工具传递到咱们手上,交通工具就是 tcp,交到咱们手上 tcp 就实现了它的工作了,剩下的就是 http 的事了,传输层协定就是干这个的。

tcp 这个货色如果真要深究,恐怕一时半会也拎不清。所以咱们依据 tcp 的两大特点:面向连贯、牢靠的来聊聊 tcp 吧。本篇咱们先来讲讲 tcp 面向连贯的这个特点吧。

面向连贯是什么?就是通信单方要先建设一条连贯通道。

说到面向连贯,你想到了什么,对了,就是那个?那个?

鼎鼎大名的 tcp 三次握手!!
每次面试面试官没少问吧?就是上面这张图:

让咱们形象化的阐明三次握手吧,三次握手的过程能够用打电话来模仿:

1、客户端说:服务器老哥你好,我是客户端,你能听失去我吗?

2、服务器说:客户端老弟你好,我是服务器,我能够听到你,请问你能够听到我吗?

3、客户端说:服务器老哥,我能够听到你。

好了,建设连贯了,让咱们开始聊天吧 ….

报文构造

开始讲三次握手先,让咱们先来看个货色:tcp 数据报文

TCP 报文是 TCP 层传输的数据单元,也叫报文段,能够看出一个残缺的报文构造由报头和数据两局部组成的。

源端口

源计算机上的应用程序的端口号,占 16 位。

目标端口

指标计算机的应用程序端口号,占 16 位。

seq(Sequence Number)

32 位序列号,它示意该报文段发送数据的第一个字节的编号,在 TCP 连贯中,传输的字节流每一个字节都有个程序编号 seq,以此来放弃传输的有序性。下面中 SYN 为 1 时,示意用于同步初始序列号(ISN)。

ack(Acknowledgment Number)

32 位确认序列号,它示意接管方冀望收到发送方下一个报文段的第一个字节数据的编号。说白点就是接受方心愿下一次发报文的时候发送方要发给我的序列号(seq)。

标记位

标记位指明该报文的行为,占用 1 位,本篇先讲上面四个标记位:

SYN

同步标记位,当 SYN=1,示意发动新的连贯。

ACK

确认标记位,只有当 ACK= 1 时确认号字段 (ack) 才无效。当 ACK=0 时,确认号有效,TCP 规定,连贯建设后,ACK 必须为 1。

PSH

推送标记位,通知对方收到该报文段后是否立刻把数据推送给下层。如果值为 1,示意该当立刻把数据提交给下层,而不是缓存起来。

FIN

标记数据是否发送结束。如果 FIN=1,示意数据曾经发送实现,能够开释连贯。

选项:选项字段,长度可变,TCP 首部能够有多达 40 字节的可选信息,用于传递附加信息。

数据:本次报文携带的数据字段。

注明:窗口大小、TCP 校验和、紧急指针字段不在本篇的探讨范畴内。

状态阐明

CLOSED: 示意初始敞开状态

LISTEN: 服务器监听状态(期待客户端的连贯)

SYN_RECEIVED(SYN_RCVD): 服务器接管到客户端的 SYN

SYN_SENT: 客户端已发送 SYN

ESTABLISHED:示意连贯已建设

下面理解了报文构造和 tcp 连贯过程几种状态,再联合下面那张三次握手的图片,咱们再来正式的了解下:

三次握手过程

1、第一次握手:客户端发送 SYN 到服务器,示意要申请建设连贯,开始进入 SYN_SENT 状态。

2、第二次握手:服务器收到申请后,回复 SYN + ACK 到客户端,示意确认了客户端的申请,此时服务器进入 SYN_RCVD 状态。

3、第三次握手:客户端收到 SYN + ACK 包,向服务器发送确认 ACK 包,客户端进入 ESTABLISHED 状态,服务器收到申请后也进入 ESTABLISHED 状态,实现三次握手。

此时 TCP 连贯胜利,客户端与服务器开始传送数据。

说到这里。置信你也能和面试官扯皮了。你认为你说完了三次握手就行了?what?你还是太年老了,这时候面试官必定会来一句:为什么是三次握手?二次或者四次不行嘛?

为什么是三次握手?

1. 确定通信单方是否具备可收发能力

嗯?如果是二次握手的话,你再看看下面那张三次握手图,

第一次握手的时候,客户端发送一个 SYN 包给服务器,第二次握手服务器回复了 ACK+SYN 给客户端,能收到服务器的确认回复这阐明了对于客户端来说,客户端能确认了服务器的接管与发送的能力没问题。

然而如果只是两次握手的话,那么问题来了,没错,客户端是能够确认服务器有收发的能力,可是服务器能确认客户端有这种能力吗?不能确认了吧,因为没法失去客户端的确认回复,服务器也不晓得发没发胜利。

2. 确定单方初始序列号

其实你看图就晓得了,三次握手的过程其实就是在互相告知初始化序列号(ISN),并确定对方曾经收到的过程。

如果只是两次握手,只有客户端的起始序列号能被确认,服务器的序列号则得不到确认。

呃。。。这个要怎么解释呢?咱们晓得 tcp 为了放弃有序,报文头部须要依附 seq 来放弃有序,所以必须在建设连贯时候单方协定一个初始序列号,后续通信都是依赖这个初始序列号,保障字节流上是有序的。

如果无奈放弃有序,可能呈现数据失落,或者乱序导致数据谬误等一系列问题,上面没法玩了。

既然三次能达到目标,那为什么还要第四次呢?浪费资源不是?

最初说到底为什么须要三次握手,因为 tcp 要放弃牢靠啊,无论是确定单方是否有接管发送的能力还是字节流传输放弃有序都算是 tcp 牢靠的一个体现了吧。

总结

本篇介绍了 tcp 并且基于 tcp 面向连贯的特点讲述了 tcp 的三次握手过程和三次握手的必要性,置信你也能和面试官扯皮了,所以你学废了么?下篇咱们讲讲 tcp 的第二个特点可靠性吧,敬请期待!

正文完
 0