概述

在网络的传输层协议中, 存在着两大悍将: TCP 和 UDP . 从前, 我傻傻的以为自己对他们虽谈不上精通, 但还是知道的, 但是, 我错了, 我被自己问住了, 我傻了. 啥也不是.

UDP

(这里为了介绍简单, 就不提数据在传输过程中的失真(纠错码)等情况了. 简单介绍一下, TCP才是今天的主角)

UDP 就是, 我把数据发给你了, 我不管你有没有收到, 反正我发出去了, 任性. 就比如我要给我的女神表白, 但是我又不好意思, 所以我托我的好兄弟马六帮我给女神带句话, 但是这个马六也脸皮薄, 他又找周三转达, 就这样虽然历经波折, 但最后还是顺利的将话带到了女神那里. 在这个过程中我做了什么? 我只是将消息送出去了, 仅此而已. 最后我满心欢喜的等待着女神的回复, 可能换回一句: 我们还是做朋友吧. 但还有一种可能, 那就是最终根本就没有送到女神那里, 中间转到周三的时候, 他因为自己的事情, 把这事给忘了, 可怜的我还苦苦的等…

UDP 虽然省事, 高效, 但是却不可靠. 因为我仅仅是发出去了, 但是我不确定你有没有收到. 不可靠有什么问题么? 上面就是个例子. 再比如, 咱俩聊天, 我给你发了一段话: 123456, 结果中间4丢了, 你收到的信息是: 12356. 这种还好, 如果快过年了, 我发给你这样一段话: 明天把你的猪宰了吧, 哎, 中间 的猪 丢了, 那估计免不了一番腥风血雨.

那如此不可靠的UDP协议, 有什么用呢? 还真有, 虽然不可靠, 但是他快啊. 在一些对数据的可靠性要求不高, 但是实时性很强的地方就有了用武之地, 比如视频电话(我也不知道底层是不是 UDP, 举个例子), 打视频电话的时候, 视频要保证其连续性, 而且中间如果丢了一帧也不会有什么影响.

但是在大多数场景下, 数据的可靠性还是要有保证的, 你从网上下载一个程序的安装包, 如果中间丢了一个字节的数据, 那可能就导致一个200mb 的文件废了, 根本不能执行.

TCP

为了保证传输数据的可靠性, TCP 诞生了. 还记得刚才我给女神表白的时候, 问题出在哪里吗? 没错, 就是因为我到最后苦苦等待, 结果她悲剧的没有收到我的心意, 伤心. 怎么办呢? 这次我想通了, 求人不如求己, 我要鼓起勇气, 我到她面前当面告诉她, 即使我多了一个朋友(没办法, 咱就喜欢交朋友), 也好过她收不到消息的好. 这下可靠了, 我确信她收到了.

区别在哪里? 不是我到他面前, 而是不管她是否愿意, 至少给爷们回句话吧. 没错, 就是回句话.

如果有这样一种机制, 每次我发出去的数据, 如果对方收到了, 就给我回句话, 告诉我收到了, 那消息就变得可靠了. 我发出去的所有消息, 都可以确信对方已经收到了.

如果数据中间丢了, 对方没有收到怎么办? 没有等到对方回复, 我就重新发一遍就好啦.
如果对方的回复丢了, 没有收到回复怎么办? 处理方式同上, 对方收到重复数据, 把重复的数据包丢弃再回复一条就好啦.

一个来自灵魂的提问, 现在的数据发送可靠吗? 我觉得是不可靠的, 现在仅仅能够保证一个数据包, 我百分百的确信对方已经收到了. 那什么样的连接才是可靠的呢?

我要发你100个数据包, 那这100个数据包你每一个都要能够收到, 并且要按照顺序将他们再拼装起来, 我觉得这样的连接才能称得上可靠. 这里面涉及到了两个概念, 确保收到 和 顺序. 确保收到我们已经做到了, 如何保证包的顺序呢? 我把要发的数据排排队, 一个一个发就行了? 天真, 如果有包1在网络中某个地方喝了杯茶, 睡了一觉, 结果接收方先收到了包2后收到包1, 顺序就乱了. 保证顺序的方式其实很简单, 在每一个包上, 都加上一个序号, 接收方按照序号从小到大把收到的包组装起来就好了.

经过改造, 现在已经基本能够保证传输的可靠性了, 到这里, 有没有发现什么? 现在和TCP的区别就是少了三次握手和四次挥手(不仅仅是). 那三次握手的意义何在?

三次握手意义何在

今天在接收了身边大神的一些思想之后, 我还是没有太明白. 不过现在, 我貌似明白了些什么. 要想知道三次握手有什么用, 就需要知道三次握手都做了什么事情.

1. 确保对方能够正常接收数据, 测试连接

还是上面的例子, 我去女神面前表白, 但不凑巧, 女神正在午休, 我站着旁边傻傻的表白, 还是没有用. 所以, 在开始之前, 我要先确保女神能够听到我说的话, 我得把她叫醒, 庄重的告诉她. 而这, 就是握手的意义.

2.建立系统开销

在发送 UDP 包的时候, 因为其不可靠性, 所以基本不会用其发送很大的文件, 因为将较大的数据拆分后发出, 中间丢了几个数据包就尴尬了. 而且 UDP 也不能够保证包的顺序, 还是一样的原因. 但是 TCP 就不一样了, 它是可靠的啊, 你可以将多个数据包分开发给我, 到我这里, 我再把他们按顺序排列好就行了. 而这个按顺序排列的操作就需要专门开辟内存空间来保存收到的数据包了, 当握手成功后, 我就会为你留下用于保存数据包的内存空间及其他一些系统资源.

而如果没有三次握手呢? 客户端发送的数据包, 可能因为某些原因(比如路不好走), 在网络中待的久了一些, 客户端因为没有收到回复, 已经放弃连接了, 但这时候, 服务器收到了这个数据包, 开辟系统资源, 返回确认包, 然后就没有然后了. 客户端已经放弃了, 根本不搭理你的回复. 系统的相关资源就白白浪费了.

3. 测试超时时间

上面说了, 当我长时间没有收到你的回复时, 我就认为你没有收到我发出的数据, 那我就需要重新发送了. 那这个长时间是多久呢? 可以在握手期间进行测试, 测量请求包的往返时间,并依此计算重传的超时时间.

4.安全性

这个确实是我没有想到的. 因为 TCP 会将数据拆分后发送, 为了保证数据的有序, 就要给每个数据包进行编号. 然后接收方根据编号的顺序对收到的包进行重组, 保证了数据的有序.

如果只是简单的123456, 那大家都知道了, 我黑客小黑, 也给你发一个编号为1的数据包, 不就把你真实的数据包给偷偷替换了么? 为了防止序列号被猜到, 就要让每次发送数据的序列号不同, 在进行握手的时候会对数据的初始序列号进行交换. 客户端第一次发送握手信息的时候, 会连着自己的初始序列号一起发过去, 服务器收到之后, 返回第二个握手信息的时候, 除了返回握手确认, 也会连着自己的初始序列号一起发回来. 这在一定程度上保证了数据的安全传输. 当然这种防护措施很弱.

这个随机的序列号其实还有另外一个作用, 我觉得这才是它最主要的作用. 如果我们上一次连接的其中一个数据包3, 在网络中傲游了一会, 连接已经断开了, 我们又开始了新的一次数据连接, 这个时候我收到了数据包3, 就会导致生成了错误的数据序列, 而随机序列号则避免了这个问题,