SSL/TLS的原理以及互联网究竟是如何工作的(8) ——奇妙的传输层!

我:都一个多月没来这里了呢,这次去拜访一下谁呢……

TCP&UDP:啊,幽灵来了啊!你都很久没来了啊,最近很忙是吗?

我:最近事情是比较多……你们两位是?

TCP:我是传输层的TCP(Transmission Control Protocol,传输控制协议)!旁观这位是同样大名鼎鼎的UDP(User Datagram Protocol,用户数据报协议),你应该都听说过吧?

我:那是自然。你是面向连接的协议,而UDP是无连接的协议;你是可靠的,而UDP是不可靠的;你们的上层协议就是那些应用层协议,你们是应用程序进程和操作系统之间的桥梁……

TCP:不错啊,幽灵,我记得一开始你来这里的时候还什么都不知道呢,结果闹了不少笑话。看来真是“士别三日,应当刮目相看”呢(笑)。不过……你知道为什么吗?
我:什么为什么?

TCP:我是说,你知道为什么我要通过三路握手建立连接呢?为什么我和UDP是应用程序进程和操作系统之间的桥梁呢?为什么我释放连接的时候也要进行三路握手呢(不过也可以通过RST直接单方面释放连接)?

我:……这还真不知道。

TCP:那我还是从头开始说吧。传输层的定位在网络层和应用层之间。网络层及以下层都是对用户隐藏的(用户无法直接与之交互),而且独立于应用程序进程工作;而应用层则是直接面对用户的,应用层协议都是配合对应的具体应用程序进程进行工作的,例如HTTP协议配合浏览器进程,XMPP协议配合IRC(Internet Relay Chat)进程,SMTP配合邮件客户端进程。工作在传输层的软件或硬件被称作transport entity(传输实体),负责实现进程间通信。

而我所在的传输层,一方面不受具体应用程序的制约,另一方面又能和用户直接交互外加对用户屏蔽下层工作细节,从而实现远程进程之间的端到端通信。要做到这一切,就必须处在应用程序进程和操作系统之间。

对了,说到进程之间的端到端通信,这里要引入一个重要概念:SAP(Service Access Point,服务访问点)。要在两个远程进程间建立连接,就必须要设置SAP。传输层的SAP是端口,被称作TSAP(Transport Service Access Point,传输服务访问点);而网络层的SAP是IP地址,被称作NSAP(Network Service Access Point,网络服务访问点)。IP地址只能定位到主机,加上端口之后才能定位到进程,进而实现端到端通信。

然后呢,网络编程中的一个重要人物就要出场了!

Socket:现在是我的专场!我叫socket(套接字),专门负责进程之间的远程通信,程序员们最熟悉我了(笑)。不管是建立连接还是维持连接还是释放连接,都需要我出马才行啊:服务器通过LISTEN开始被动监听,准备建立连接;客户端发出CONNECT命令,主动要求建立连接;服务器接收到命令之后就ACCEPT,连接建立了!然后呢,客户端发送RECEIVE命令,要求收到指定的数据;服务器收到之后就SENT,把指定数据发送出去;最后,服务器和客户端都发送CLOSE命令,释放连接。

这些命令都是通过socket实现的,而且所有的socket都引用了前面提到的SAP以访问对应的进程。

我:快头晕了……

TCP:别急,下面就开始说有意思的事了。你有没有想过,三路握手其实很麻烦啊?为什么不能直接就建立连接呢?比如说直接发送连接建立请求和数据过去,然后马上就处理好了,干嘛还要对方确认再正式建立连接呢?

我:是为了保证可靠吧……具体我也不清楚

TCP:并不是为了保证可靠。可靠的含义是:1,先发送的先到达;2,出现丢包和损坏等数据没被正常送到的情况时,保证重传。

第一点是通过建立虚电路实现的,一个连接只有一条路由路径;而要实现第二点也很简单,一方传输数据和连接请求过去之后要求对方发送确认信息即可。

可是,还有一个很严重的问题没有解决:假设一个客户端给服务器发送了带着数据的连接请求,但是却因为网络拥塞而超时了;那么此时客户端会重新发送之前的请求,这次没有超时,成功建立了连接。

问题在于,一段时间之后最开始的那个请求也到达了,结果就是服务器没法识别出这是雷同请求,然后又建立连接了!

我:这会造成什么严重后果吗?

TCP:会造成极为严重的后果!想象一下这样一个场景:客户端向银行服务器发送请求,要求向一个账户转入一万美元;结果发生了前面所说的状况,那么最终结果就是转入了两万美元,但客户端却一无所知!

我:这听起来真够糟糕的。不过,可以给每个连接都加上独一无二的序列号啊?

TCP:听起来不错,问题在于……服务器出于性能上的考虑,并不会专门建立一个序列号数据库来记住那些连接的不同序列号的。

我:(汗)那就只能先不发送数据,只发送连接建立请求,然后服务器发送确认信息,客户端再发送数据;这样一来,后来雷同请求来了之后,服务器端就会先问客户端是不是真的想要建立连接,然后客户端就会发现异常从而拒绝了。

TCP:没错,就是这样!这一过程就是我的三路握手(three-way handshake)!当然实现的时候就没这么简单了,但基本思路就是这样的!

我:哈哈,被我猜对了啊!

TCP:接下来该说说怎样释放连接了。如果对方主机长时间无响应或者断网了抑或是出现了其他异常状况,另一方就会直接发送RST包单方面释放连接。

但是在正常情况下,当通信完成时,我并不会单方面释放连接的。

我:为什么呢?

TCP:想象一下,一个客户端发送了最后一个请求,然后服务器响应之后就单方面释放连接了,可是响应数据包丢失了。那么,客户端就会请求重传,但此时服务器已经释放了连接,不会再理会客户端了。

我:那么这数据就永远丢失了!

TCP:是啊。不过呢,释放连接比建立连接要难弄的多了。我先说一个故事吧:有一个山谷,山谷里驻扎着一只三人军队,叫A队;两边的山顶上分别驻扎着B队的两个分队,每个分队各两人。B队想要消灭A队,但是如果分队单独行动,那么一定会输的。

我:那就想办法同时行动啊。

TCP:这是自然。问题在于,B队的两个分队要想取得联系,只能派斥候(斥候没有战斗力,不算分队成员)走过山谷去通知对方。而斥候是有可能被抓的,也就是说不保证消息能送到。在无法确定对方是否收到消息的情况下,不管哪个分队都不会行动的。

我:那么,在分队1的斥候到达分队2把消息带来之后,分队2再派斥候把确认消息带过去就行了啊?

TCP:真的吗?带确认消息的斥候也是有可能被抓的!如果说斥候被抓了,那还不是没法确定对方是否收到消息?

我:那就再派斥候把确认消息收到的确认消息传回去(这话说起来怎么这么绕口)……
TCP:还是不行啊!确认消息的确认消息还是有可能送不到啊。最关键的一点在于,最后一个斥候是否到达是无法被确认的;那么送出最后一个斥候的分队就会犹豫对方是不是收到了确认信息,会不会同时攻击A队。一旦这么犹豫了,分队就不会参加攻击行动,那么也就无法战胜A队了。

现在,试着把斥候换成计算机网络中的不可靠通信信道,把攻击命令换成连接释放命令吧。

我:这么说实际上根本就做不到一起释放连接了?

TCP:不,实际情况反倒好办很多:还是拿前面的例子,在完成最后一次数据传递后,客户端发送FIN包,服务器端接收到之后发送FIN+ACK包,同时释放连接;客户端接收到ACK包或者长时间接收不到响应,都会释放连接。

我:相当于不管不顾了。不过既然本来就是个无解的问题,那也只能这么办了。
TCP:啊,这次扯了太多了,对不起,UDP你只能下次再出场了。

UDP:好吧,T!C!P!

科普文链接集合:
https://plus.google.com/+GhostAssassin/posts/a8aKzvZLsuV

原文:https://plus.google.com/+GhostAssassin/posts/WQkk6sHQPoo

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s