browser

TCP 实习笔记

Breeze

Breeze

— 阅读时间 7 分钟
分享

计算历：7e3 年 af 月 5e 日。天气：晴。在 Chrome 实习的第一天。

终于摆脱学校开始在 Chrome 实习啦，真是不错的一天，网络很好，没有丢包情况出现，现实的情况也没老师说的那么糟糕嘛。

前辈的工作台也太炫酷了吧，就是不知道在 FireFox 实习的同学怎么样，IE 那的同学，估计是手动操作吧！哈哈！！

今天用这工作台发了不少报文，工作台用起来比学校里手动操作报文快了不少，但基础不能忘，今天没什么需要记录的，就复习下 TCP 报文基础吧。

TCP，Transmission Control Protocol，传输控制协议，传输层的一个协议，其目的为：在复杂网络情况下（不可靠的 IP 协议下），提供一个可靠的字节流传输通道。

可靠意味着数据的完整，也就是，在网络连通的情况下，排除一切可能的错误，将应用层的数据完完整整的发送到对方的应用层。

那么如何排除错误，对于未到达对方的报文（包括可能已经到达但对方未返回确认的），进行不断的重发！直到对方确认收到为止。

OK 现在先过一过基础。

组成

首先，先复习下报文的组成：

TCP 报文

一个完整的报文包含以上信息，按照顺序有如下作用：

区域 占用字节 含义
源端口 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 个步骤

  1. 一端请求开启/关闭
  2. 另一端确认开启/关闭
  3. 另一端请求开启/关闭
  4. 一端确认开启/关闭

只不过通道的开启过程中，第 2 步和第 3 步进行了合并。

OK 整理的差不多，这些是基础，也是最重要的部分，虽然前辈的工作台会帮忙做掉这些步骤，但万一机器出故障了呢，作为 TCP 学院的优等生，我要确保数据始终能到达服务端！！

对了！前辈的工作台还是有一些东西没有用到，那个大屏幕上的信息还没充分了解，不过也了解个大概了，明天在去仔细研究研究。

相关阅读

阅读更多

JavaScript 对象 & 原型

前言 这次的 why what or how 主题：JavaScript 对象 & 原型。 此类文章在百度上一搜一大把，其实不用再写了，但是本着把这个问题解释的清清楚楚明明白白，还是开始写了。 原因如下： 1. 面试宝典类文章，弄张图片一糊弄，让人觉得自己理解了。 2. 解释类文章，告诉你一堆语法，对语法一顿解释，告诉你就是这样的，还是没说清楚。 3. 很少有文章单独解释这个点！但这个点是基础！真的很重要！ 所以本篇文章想说一说对象 & 原型，但为了确保能顺利理解，请先看完 JS 变量存储？栈 & 堆？NONONO!，因为该篇文章从变量存储的角度来解释 JavaScript 对象 & 原型，请确保看完，在看这篇文章。 什么是对象？ 既然要说清楚，

By Breeze

浏览器下的 Event Loop

前言 javascript 是以单线程的形式运行在宿主环境下，javascript 采用了回调的形式来解决异步任务。 为什么是单线程？ javascript 的最开始的出现是为了给 web 页面增添一些动态的效果，那么就避免不了获取页面上的元素信息，如果 javascript 是以多线程的形式运行在浏览器内，如果两个线程内的 javascript 同时去获取/修改，某个页面上的元素，那么浏览器该让哪个 javascript 线程拥有获取/修改该元素的权限呢？由于元素的信息会经常性的发生变化，那么又改如何去同步各个线程内所保存的元素信息呢？ 所以综合以上问题， javascript 是单线程的原因就显示意见了，单线程在执行时，对于元素信息的引用在同一时间仅可能只有一个，那么以上所有的问题都不存在了。 什么是异步任务？ 任何代码在执行时，都会碰到一些需要经过大量时间运算或是等待的代码，在浏览器的环境下，常见的就是 http 任务，比如：资源的加载（图片的 onload 事件），ajax 的请求（XMLHttpRequest 的 onLoad 事件）还有页面元素的点击事件以及

By Breeze

node 下的 Event Loop

前言 通过 浏览器下的 Event Loop ，可以得知 javascript 是一门事件驱动的语言， javascript 主线程通过不断的调用事件队列中的事件来完成异步任务。那么 Node 下是否也是如此？ Node 下的事件队列 在 Node 官网有这样一篇文章：The Node.js Event Loop, Timers, and process.nextTick() 。 该文章主要讲述了 Node 中是如何处理以及实现 Node 下的 Event Loop。 主要包含以下内容： 事件队列 不同于浏览器，Node 下的有 6 个事件处理阶段，其执行顺序和队列名称如下： ┌───────────────────────────┐ ┌─>│ timers │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ pending callbacks │ │ └─────────────┬─────────────┘ │

By Breeze

什么是 HTML 5？

前言 作为程序员，技术的落实与巩固是必要的，因此想到写个系列，名为 why what or how 每篇文章试图解释清楚一个问题。 这次的 why what or how 主题：现在几乎所有人都知道了 HTML5 ，那么 H5 到底相比于 HTML4 有什么区别呢？ 升级版？标准版！ HTML5 做为 HTML 标准的第 5 版，于 2014 年发布，相信关注过 HTML5 的发展史的朋友都知道该版本是 WHATWG 和 W3C 握手言和后诞生的，是 W3C 组织与浏览器厂商相互妥协的结果，其中的绝大部分规范都由 WHATWG 组织所制定，之后由 W3C 采纳并入标准中。

By Breeze