计算历:7e3 年 af 月 5e 日。天气:晴。在 Chrome
实习的第一天。
终于摆脱学校开始在 Chrome
实习啦,真是不错的一天,网络很好,没有丢包情况出现,现实的情况也没老师说的那么糟糕嘛。
前辈的工作台也太炫酷了吧,就是不知道在 FireFox
实习的同学怎么样,IE
那的同学,估计是手动操作吧!哈哈!!
今天用这工作台发了不少报文,工作台用起来比学校里手动操作报文快了不少,但基础不能忘,今天没什么需要记录的,就复习下 TCP
报文基础吧。
TCP
,Transmission Control Protocol
,传输控制协议,传输层的一个协议,其目的为:在复杂网络情况下(不可靠的 IP
协议下),提供一个可靠的字节流传输通道。
可靠意味着数据的完整,也就是,在网络连通的情况下,排除一切可能的错误,将应用层的数据完完整整的发送到对方的应用层。
那么如何排除错误,对于未到达对方的报文(包括可能已经到达但对方未返回确认的),进行不断的重发!直到对方确认收到为止。
OK
现在先过一过基础。
组成
首先,先复习下报文的组成:
一个完整的报文包含以上信息,按照顺序有如下作用:
区域 | 占用字节 | 含义 |
---|---|---|
源端口 | 16 |
TCP 通道所在进程的端口号,也就是我的工作间的门牌号。 |
目标端口 | 16 |
TCP 通道另一侧进程所在的端口号,估计也是和我一样的工作间。 |
序号 | 32 | 当前报文中所携带数据中第一个字节的序号,对方会根据该序号进行数据的拼接,号码是多少不重要,重要的是要连续。 |
确认序号 | 32 | 确认报文中使用,告知对方该序号前的报文已成功接收。 |
数据偏移 | 4 | 由于 TCP 首部长度不确定,对方根据该字段就可以知道 TCP 首部长度。 |
保留位 | 6 | 目前未使用,置 0 即可。 |
URG |
1 | 紧急标志位,标志该报文是否需要优先处理,主要是对自己这边的进程起作用。 |
ACK |
1 | 表明当前为确认报文,告知对方确认序号之前的数据已完整接收。 |
PSH |
1 | 推送标志位,通知进程将将缓存区的数据推送出去。 |
RST |
1 | 通道重置标志位,通知对方重置 TCP 通道。 |
SYN |
1 | 同步标志位,通知对方开启 TCP 通道。 |
FIN |
1 | 结束标志位,通知对方请求单向关闭 TCP 通道。 |
窗口 | 16 | 告诉对方,自己目前还有多少的缓存区可以使用,避免 TCP 报文因为没有缓冲区而不接受的情况。 |
校验和 | 16 | 验证当前数据的完整性,由己方生成,并在对方校验。 |
紧急指针 | 16 | 与 URG 配合使用,标志紧急数据的大小。 |
选项 | 不固定 | 一些其他选项,为 TCP 发展后的一些补充。 |
填充 | 不固定 | 使得 TCP 报文首部长度为 32 的整数倍。 |
数据 | 不固定 | 需要传输的数据。 |
其中选项中还有不少内容,下次主要复习这块,这里先过。
连接与释放
TCP
既然表现为一个通道,那么通道的连接与释放当然是重中之重。
※ 三次握手。
网络是个复杂的环境,一个稳定的通道需要双方都清楚对方已经自己发送和接收的能力,这就是三次握手的由来。
第一次握手(客户端请求建立连接):
* | 客户端发送能力 | 客户端接收能力 | 服务端发送能力 | 服务端接收能力 |
---|---|---|---|---|
客户端 | × | × | × | × |
服务端 | √ | × | × | √ |
- 客户端:虽然客户端发送了请求,但却不清楚自己是否真的将报文发送到了服务端,因此客户端并不知道自己和对方的能力。
- 服务端:服务端接收到了报文,就能知道客户端有能力发送,自己有能力接收。
第二次握手(服务端收到报文,确认连接并请求连接):
* | 客户端发送能力 | 客户端接收能力 | 服务端发送能力 | 服务端接收能力 |
---|---|---|---|---|
客户端 | √ | √ | √ | √ |
服务端 | √ | × | × | √ |
- 客户端:若返回的报文通过验证,说明自己有能力发送服务端有能力接收,接收成功说明自己有能力接收,服务端有能力发送。
- 服务端:和第一次握手一样,服务端虽然发了报文,但却不知道报文是否能正确到达。
第三次握手(客户端收到报文,确认连接):
- | 客户端发送能力 | 客户端接收能力 | 服务端发送能力 | 服务端接收能力
客户端 | √ | √ | √ | √ |
服务端 | √ | √ | √ | √ |
- 客户端:在第二次握手过程中,客户端就已经确认双方的能力,
- 服务端:与第二次握手的客户端一样,若报文通过验证,说明自己有能力发送客户端有能力接收。
至此一个稳定的通道建立成功。
※ 四次挥手
通道的建立需要消耗计算机资源,因此当数据传输完毕后,如何进行释放,也是重要的一环。
如何正确的关闭通道,是我们需要思考的问题。
一个通道的关闭,和开启一样,一个巴掌拍不响,需要双方都进行确认。
- 第一次挥手:客户端请求关闭连接。
- 第二次挥手:服务端确认客户端的关闭请求。
- 第三次挥手:服务端请求关闭连接。
- 第四次挥手:客户端确认服务端的关闭请求。
经过四次挥手,通道在双方都知晓的情况下销毁,而不会出现一方销毁另一方却仍存在的情况,计算机资源也可得到相应的释放。
那么为何不能像建立通道一样,只进行三次?
很简单,通道的开启是双方同时开启,而关闭却不是,当客户端关闭了通道,仅仅代表客户端不发送数据了,而服务端却可以继续发送数据,客户端仍可以接收数据。
小结
通道的开启与关闭,其实是相同的,需要 4
个步骤
- 一端请求开启/关闭
- 另一端确认开启/关闭
- 另一端请求开启/关闭
- 一端确认开启/关闭
只不过通道的开启过程中,第 2
步和第 3
步进行了合并。
OK
整理的差不多,这些是基础,也是最重要的部分,虽然前辈的工作台会帮忙做掉这些步骤,但万一机器出故障了呢,作为 TCP
学院的优等生,我要确保数据始终能到达服务端!!
对了!前辈的工作台还是有一些东西没有用到,那个大屏幕上的信息还没充分了解,不过也了解个大概了,明天在去仔细研究研究。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。