在TCP/IP层面上一封邮件的发送,接收流程

本文内容复制于《图解TCP/IP》第五版中第二章节第五小节,讲的挺详细的。

假设甲给乙发送电子邮件, 内容为: “早上好”。 而从TCP/IP通信上看, 是从一台计算机A向另一台计算机B发送电子邮件。 我们就通过这个例子来讲解一下TCP/IP通信的过程。
■ ① 应用程序处理
启动应用程序新建邮件, 将收件人邮箱填好, 再由键盘输入邮件内容“早上好”, 鼠标点击“发送”按钮就可以开始TCP/IP的通信了。
首先, 应用程序中会进行编码处理。 例如, 日文电子邮件使用ISO-2022-JP或UTF-8进行编码。 这些编码相当于OSI的表示层功能。
编码转化后, 实际邮件不一定会马上被发送出去, 因为有些邮件的软件有一次同时发送多个邮件的功能, 也可能会有用户点击“收信”按钮以后才一并接收新邮件的功能。 像这种何时建立通信连接何时发送数据
的管理功能, 从某种宽泛的意义上看属于OSI参考模型中会话层的功能。
应用在发送邮件的那一刻建立TCP连接, 从而利用这个TCP连接发送数据。 它的过程首先是将应用的数据发送给下一层的TCP, 再做实际的转发处理。

■ ② TCP模块的处理
TCP根据应用的指示(这种关于连接的指示相当于OSI参考模型中的会话层。 ) , 负责建立连接、 发送数据以及断开连接。 TCP提供将应用层发来的数据顺利发送至对端的可靠传输。
为了实现TCP的这一功能, 需要在应用层数据的前端附加一个TCP首部。 TCP首部中包括源端口号和目标端口号(用以识别发送主机跟接收主机上的应用) 、 序号(用以发送的包中哪部分是数据) 以及校验和
(Check Sum, 用来检验数据的读取是否正常进行的方法。 ) (用以判断数据是否被损坏) 。 随后将附加了TCP首部的包再发送给IP。

■ ③ IP模块的处理
IP将TCP传过来的TCP首部和TCP数据合起来当做自己的数据, 并在TCP首部的前端在加上自己的IP首部。 因此, IP数据包中IP首部后面紧跟着TCP首部, 然后才是应用的数据首部和数据本身。 
IP首部中包含接收端IP地址以及发送端IP地址。 紧随IP首部的还有用来判断其后面数据是TCP还是UDP的信息。
IP包生成后, 参考路由控制表决定接受此IP包的路由或主机。 随后, IP包将被发送给连接这些路由器或主机网络接口的驱动程序, 以实现真正发送数据。
如果尚不知道接收端的MAC地址, 可以利用ARP查找。 只要知道了对端的MAC地址, 就可以将MAC地址和IP地址交给以太网的驱动程序, 实现数据传输。


路由控制表:存储了可以到达的网络目的地址范围和如何到达的路由信息。
ARP可以从数据包的IP地址中解析出物理地址(MAC地址)的一种协议。

■ ④ 网络接口(以太网驱动) 的处理
从IP传过来的IP包, 对于以太网驱动来说不过就是数据。 给这数据附加上以太网首部并进行发送处理。
以太网首部中包含接收端MAC地址、 发送端MAC地址以及标志以太网类型的以太网数据的协议。 根据上述信息产生的以太网数据包将通过物理层传输给接收端。 
发送处理中的FCS由硬件计算, 添加到包的最后。 设置FCS的目的是为了判断数据包是否由于噪声而被破坏。


包流动时, 从前往后依此被附加了以太网包首部、 IP包首部、 TCP包首部(或者UDP包首部) 以及应用自己的包首部和数据。 
而包的最后则追加了以太网包尾(包首部附加于包的前端, 而包尾则指追加到包的后端的部分。 )。
每个包首部中至少都会包含两个信息: 一个是发送端和接收端地址, 另一个是上一层的协议类型。
经过每个协议分层时, 都必须有识别包发送端和接收端的信息。 以太网会用MAC地址, IP会用IP地址, 而TCP/UDP则会用端口号作为识别两端主机的地址。 
即使是在应用程序中, 像电子邮件地址这样的信息也是一种地址标识。 这些地址信息都在每个包经由各个分层时, 附加到协议对应的包首部里边。
此外, 每个分层的包首部中还包含一个识别位, 它是用来标识上一层协议的种类信息。 例如以太网的包首部中的以太网类型, IP中的协议类型以及TCP/UDP中两个端口的端口号等都起着识别协议类型的作用。
就是在应用的首部信息中, 有时也会包含一个用来识别其数据类型的标签。

包的接收流程是发送流程的逆序过程。
■ ⑤ 网络接口(以太网驱动) 的处理
主机收到以太网包以后, 首先从以太网的包首部找到MAC地址判断是否为发给自己的包。 如果不是发给自己的包则丢弃数据(很多NIC产品可以设置为即使不是发给自己的包也不丢弃数据。 
这可以用于监控网络流量。 ) 。
而如果接收到了恰好是发给自己的包, 就查找以太网包首部中的类型域从而确定以太网协议所传送过来的数据类型。 在这个例子中数据类型显然是IP包, 因此再将数据传给处理IP的子程序,
 如果这时不是IP而是其他诸如ARP的协议, 就把数据传给ARP处理。 总之, 如果以太网包首部的类型域包含了一个无法识别的协议类型, 则丢弃数据。

■ ⑥ IP模块的处理
IP模块收到IP包首部及后面的数据部分以后, 也做类似的处理。 如果判断得出包首部中的IP地址与自己的IP地址匹配, 则可接收数据并从中查找上一层的协议。 
如果上一层是TCP就将IP包首部之后的部分传给TCP处理; 如果是UDP则将IP包首部后面的部分传给UDP处理。 
对于有路由器的情况下, 接收端地址往往不是自己的地址, 此时, 需要借助路由控制表, 在调查应该送达的主机或路由器以后再转发数据。

■ ⑦ TCP模块的处理
在TCP模块中, 首先会计算一下校验和, 判断数据是否被破坏。 然后检查是否在按照序号接收数据。 最后检查端口号, 确定具体的应用程序。
数据接收完毕后, 接收端则发送一个“确认回执”给发送端。 如果这个回执信息未能达到发送端, 那么发送端会认为接收端没有接收到数据而一直反复发送。
数据被完整地接收以后, 会传给由端口号识别的应用程序。

■ ⑧ 应用程序的处理
接收端应用程序会直接接收发送端发送的数据。 通过解析数据可以获知邮件的收件人地址是乙的地址。
如果主机B上没有乙的邮件信箱, 那么主机B返回给发送端一个“无此收件地址”的报错信息。
但在这个例子中, 主机B上恰好有乙的收件箱, 所以主机B和收件人乙能够收到电子邮件的正文。 邮件会被保存到本机的硬盘上。
 如果保存也能正常进行, 那么接收端会返回一个“处理正常”的回执给发送端。 反之, 一旦出现磁盘满、 邮件未能成功保存等问题, 就会发送一个“处理异常”的回执给发送端。
由此, 用户乙就可以利用主机B上的邮件客户端, 接收并阅读由主机A上的用户甲所发送过来的电子邮件——“早上好”。

猜你喜欢

转载自www.cnblogs.com/wl-sjy/p/12625111.html