到底是TCP还是HTTP决定数据的边界?

http是tcp的上层,由于tcp是面向字节流的,这里一次 http请求有多少内容,是否是由http控制并决定边界的?

有一个客户他的名字不叫老王,而是叫http,是美国人。这个美国人想邮递点物品给自己的好友,于是联系一家叫TCP的快递公司。

TCP快递公司最鲜明的特点,不理解也不关心运输的是什么物品,统统看成一个又一个字节。

客户http一次性扔进TCP快递公司仓库10000字节,TCP快递公司对于这10000个字节分别编号(1,2,3,4,。。。9999,10000)。假设每辆卡车最大有效载荷(Maximum Segment Size )为1000字节,那么10辆卡车恰好运完。

至于这10辆卡车发车间隔以及多长时间能运完,客户http无法控制,TCP快递公司会尽力而为。如果运完了货物,客户和TCP快递公司说,将TCP连接释放掉。

Short Lived Connection
那么TCP这家快递公司就不再浪费大脑来记忆目前的字节流编号为10000了,内存释放掉了,那么记忆的这些内容也随同一起释放。

过一会客户http又要快递一点物品,这次是1800字节。快递公司又从头对物品开始编号(1,2,3,。。。1799,1800)。第一辆卡车运1000字节,第二辆卡车运800字节。

把这些字节发出去之后,每一个字节都获得了ACK确认。运完了货物,客户和TCP快递公司说,将TCP连接释放掉。以下内容和上文是雷同的,故忽略。

Long Lived Connection

如果第一次运完10000字节,客户和快递公司说,把当前的连接继续保持。那么快递公司就会乖乖地记忆最关键的内容,字节流的当前编号是10000。

当客户第二次要快递1800字节时,由于之前的连接依然存在,快递公司需要对货物进行编号了,是这么来编号的(10001,10002,10003。。。,11799,11800),接下来的细节和上文有一次雷同。

这个http客户挺奇怪的,为何不一次性运输11800字节,而是要分两次运输?

其实这并不奇怪,好比你第一次给远方的好友快递大闸蟹,过两天又想到了山核桃给他快递过去。

TCP这家快递公司,自身是不会产生字节流的,它的字节流都来自于客户。换句话说,数据的源头来自于与人类打交道的应用层,比如http。

TCP只关心按照客户提交数据的先后顺序,对数据所对应的字节进行编号,还会清晰地记忆这些编号。至于数据本身是什么涵义,对不起,快递公司并不关心。

那么作为客户的http,自然要对自己的数据负责,要知道数据的最终接收者,是一台机器而不是人。而要让机器明白里面的货物是大闸蟹还是山核桃,需要按照协议标准来将数据组织好。

组织好之后就可以提交给TCP快递公司了,而接收方通过到达的字节流,可以按照http协议的定义,将内容提取出来,哦,第一次原来是10斤大闸蟹,第二次原来是5斤山核桃。。。如果没有协议定义,机器是不会知道接收到的字节流代表什么含义的。

来源:车小胖谈网络,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/125888

发表评论

登录后才能评论
侵权联系
返回顶部