计算机网络基础知识

To

记录计算机网络学习的笔记.

1. 计算机网络和因特网

互联网是一个连接了全世界数以亿计的计算设备的网络. 以前这些计算设备通常是传统的桌面PC, Linux工作站或者说是服务器(用于提供存储传输Web页面和电子邮件等信息). 而现在越来越多非传统的因特网设备和因特网相连(如手机, 平板, 相机, 汽车等). 所有这些设备都称为主机(host)或端系统(end system).

端系统通过通信链路(communication link)和分组交换机(packet switch)连接到一起.

  • 通讯链路: 可能是同轴电缆, 铜线, 光纤等, 不同链路提供不同的速率.
  • 分组交换机: 可能是路由器(router), 链路交换机(link-layer switch)等.

当一台端系统向另一台端系统发送数据时, 发送端会把数据分段, 为每段加上首部字节, 形成数据包分组(packet, 也叫数据包), 然后分组交换机就负责将这些分组, 向着它们需要到达的地方转发传输.

1.1 网络的核心部分

在应用层中, 端系统之间彼此交换的是报文(message), 报文中包含协议设计者需要的任何东西. 可以理解成不同的内容, 比如可以执行的内容, 也可以是数据(电子邮件数据, JPEG图像或者是音频等). 为了能移动这些报文(也就是数据), 通过网络链路和交换机来实现有两种基本方法.

  • 分组交换(packet switching)
  • 电路交换(circuit switching)

下面就只讲用得比较多的的分组交换:

1.1.1 分组交换

分组交换会将长报文划分为较小的数据块, 称之为分组(packet). 多数分组交换机在链路的输入端采用存储转发传输机制(store-and-forward transmission). 简单来说就是分组交换机在转发一个分组之前, 需要从上游接收并缓存整个分组. 对于每个分组交换机, 它有多条输出链路, 也就是转发到下一跳, 对于每条输出链路分组交换机会有一个输出缓存(output buffer) (也叫输出队列output queue).

缓存队列是在路由器内的, 图中为了展示它所以画在了外面. 图中蓝色小方块为一个分组(packet), 红色的为丢失的分组.
如果到达的分组需要传输到某条链路, 但发现链路正忙于传输其他分组, 那么到达分组需要在输出缓存中等待, 如果缓存满了那么就会出现分组丢失(丢包, 也就是图中红色的小方块). 到达的分组或者排队中的分组之一会被丢弃.
因此数据传输过程中除了存储转发时延以外, 分组还要承受输出缓存的排队时延(queue delay).

那路由器是怎么知道分组要转发给哪个路由呢?

不同计算机网络是使用不同的方式完成的, 下面就简要说一下因特网中采用的方法.
在因特网中每个端系统具有一个IP地址, 报文划分为分组时, 分组的首部就包含了目的地的IP地址. 当一个分组到达网络中的路由器时, 路由器会检查该分组的目的地址, 将该地址与路由器自身维护的转发表(forwarding table)对照查询, 查询到适当的输出链路, 那么路由器就会将该分组导向该出链路.
至于转发表是怎么来的, 作者说后面再说. 总之因特网具有一些特殊的路由选择协议(routing protocol)用于自动设置这些转发表.

1.2 分组交换的时延

分组从一个结点沿路到后继节点过程中, 它在每个结点都经受了几种不同类型的时延. 其中最重要的为:

  • 结点处理时延(nodal processing delay): 检查比特级别的差错需要的时间, 检查首部以及决定将该分组导向何处需要的时间.
  • 排队时延(queuing delay): 取决于先到达的正在排队的分组数量.
  • 传输时延(transmission delay): 取决于分组的长度以及链路的传输速率.
  • 传播时延(propagation delay): 取决于链路的物理媒体(光纤, 双绞铜线等). 也与链路的长度有关.

1A 体系结构

1A.1 结构模型

首先是OSI和TCP/IP的分层模型和对应关系:

OSI参考模型一共分7层, 一般用于教学, 实际使用更多的是TCP/IP的5层模型. 5层体系模型为:

  • 应用层: 网络应用程序以及他们的应用层协议留存的地方. (如: HTTP提供Web文档请求和传送; SMTP提供电子邮件报文的传输; FTP提供两个端系统间文件传送; DNS域名解析系统等) 位于应用层的信息分组称为报文(message).
  • 运输层: 因特网的运输层在应用程序端点之间传送应用层报文. 因特网中有TCP和UDP这两种协议. TCP向应用程序提供了面向连接的服务, 包括应用层报文确保传递和流量控制机制, 会将长报文划分为短报文, 并提供拥塞控制机制. UDP面向无连接, 上面TCP有的它没有. 位于运输层的分组称为报文段(segment).
  • 网络层: 负责将称为数据报(datagram)的网络分组从一台主机移动到另一台. 上一层运输层会给网络层提供 报文段 和 目的地址 . 这一层包括著名的IP协议与许多路由选择协议, 但通常也会被称为IP层.
  • 链路层: 链路层负责将数据报传递给下一个结点. 它提供的服务取决于应用于该链路层的特定链路协议. 比如某些协议基于链路提供可靠传递, 但是这种可靠传递不同于TCP的端系统对端系统的可靠交付, 而是包括以太网, WiFi和电缆接入网的DOCSIS协议. 因为数据报从源到目的地传送通常需要经过几条链路, 所以一个数据报可能被沿途不同链路上的不同链路层协议处理. 链路层的分组称为(frame).
  • 物理层: 物理层的任务是将帧中的一个个比特从一个结点移动到下一结点. 这一层中的协议仍是链路相关的, 并且进一步与该层链路(例如: 双绞铜线, 单模光纤)的实际传输媒体相关. 比如: 以太网就有许多物理层协议, 有基于双绞铜线的, 有基于同轴电缆的, 还有基于光纤的… 在每种场合, 跨越这些链路移动一个比特是以不同的方式进行的.

作者举的快递的例子非常容易理解: 我们在网上买东西, 首先确定自己所在的位置有相应的快递网点, 这个网点就相当于网络接入层, 然后需要告诉卖家地址, 这个地址相当网际互联层, 快递送货相当于传输层, 最后我们收到货物之后拆包使用相当于应用层.
而在BS结构中, TCP/IP模型中的网络接入层没有相应协议, 网际互联层是IP协议, 传输层是TCP协议.

我们来看一下这套结构模型在实际中是怎么运作的:

可以看到用户A发送的数据, 经过一层一层封装(encapsulation)后发送到用户B的电脑, 然后再一层一层的拆开, 最终用户B得到用户A发送的消息, 这就是模型基本运作的样子.

2. 应用层

2.1 应用层原理

网络应用程序的体系结构大致可以分为:

  • CS结构(client-server architecture): 由一个或多个客户端, 以及一个或多个服务端组成.
  • P2P结构(P2P architecture): 每终端都是客户端和服务端.

下图展示了两个端系统应用层之间是如何通讯的:

从一个端系统的进程向另外一个端系统的进程, 进程通过一个叫套接字(socket)的软件接口向网络发送报文和接收报文, 套接字是同一台主机内应用层与运输层之间的接口. 应用程序的开发者可以控制套接字在应用层端的一切, 但是对于该套接字的运输层端几乎没有控制权. 所以开发者对运输层的控制仅限于选择运输层协议设定几个运输参数.

在因特网中, 主机由其IP地址(IP address)标识, 而接收进程由目的地端口号(port number)标识. 一般主机都给流行的应用分配了特定的端口号, 比如Web服务器用端口号80来标识, 邮件服务进程(使用SMTP协议)用端口号25来标识.

而在套接字另一侧是运输层协议负责把该报文传入接收进程的套接字. (如TCP/UDP协议等)
注:而无论TCP还是UDP都没有提供任何加密机制, 也就是传进套接字的数据, 跟到达目的地进程的数据是一样的. 意思就是如果中途链路有人嗅探, 那么他能看到传输的数据. 因此为了隐私和其他安全问题现在已经研制了加强版安全套接字层(Secure Sockets Layer, SSL). 它能提供进程到进程的安全性服务, 但它和TCP和UDP不在同一个层次上, 它是对TCP的加强, 这种强化是在应用层实现的.

2.2 应用层协议(application-layer protocol)

应用层协议定义了不同端系统上的应用程序进程如何相互传递报文. 比如报文类型, 报文语法, 字段语义, 何时如何发送等.

2.2.1 Web和HTTP

Web的应用层协议是超文本传输协议(HyperText Transfer Protocol, HTTP). Web页面(Web page)(也叫文档)是由对象(object)组成的, 如一个HTML文件, 一个JPEG图形, 一个Java小程序这样的文件就是对象. 多数Web页面含有一个HTML基本文件(base HTML file)以及几个引用对象. 例如一个Web页面包含HTML文本和5个JPEG图形, 那么这个Web页面就有6个对象. 而Web浏览器(Web browser)实现了HTTP客户端, Web服务器(Web server)实现了HTTP的服务器端. 服务器向用户发送被客户端请求的资源, 假设一个用户在短短几秒钟内两次请求同一个对象, 但是服务器并不会因为刚刚给用户发送了它就不发送了, 而是和第一次请求时一样重新发送资源, 就好像服务器不记得之前做过这件事情一样. 因为HTTP服务器不会保存用户的相关信息, 所以我们说HTTP是一个无状态协议(stateless protocol).

我们都知道HTTP协议作为应用层的协议, 他在发送请求和接收报文时会使用传输层的TCP协议, 而TCP协议在建立连接时是需要进行”三次握手”的. 而在很多因特网应用程序中, 客户在一台服务器上停留的时间是比较久的, 如果客户的每一次请求和响应都需要经历”三次握手”, 那会消耗公用的网络资源. 所以就有请求和响应在一次TCP连接中完成, 而不是每次请求和响应都要建立一次TCP连接. 这就是持续性连接(persistent connection)和非持续性连接(non-persistent connection)的区别.

HTTP请求报文
下面是一个典型的HTTP请求报文:

1
2
3
4
5
GET /somedir/page.html HTTP/l.l
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

它的第一行叫做请求行(request line), 其后继的行叫做首部行(header line).
请求行:

  • 第一个字段是请求方法字段, HTTP1.0包括GET, POST, HEAD; HTTP1.1新增了, OPTIONS, PUT, PATCH, DELETE, TRACE, CONNECT.
  • 第二个字段是URL字段. 统一资源定位符.
  • 第三个字段是HTTP版本字段.

首部行:

  • Host: 指明主机, 用于Web代理高速缓存.
  • Connection: close. 这一行表示不希望用持续性连接, 要求服务器发送完被请求对象后就关闭连接.
  • User-agent: 指明用户代理, 发送请求的浏览器类型.
  • Accept-language: 用户想得到该对象的什么语言的版本(如果服务器支持的话).

下图是请求报文通用格式, 如果是GET方法时实体主体为空, 如果是POST就可以包含实体主体. 而GET可以在URL中用?带参.

下面是典型的HTTP响应报文:

1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
Connection: close
Date: Tue , 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue , 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

它由三个部分组成: 一个初始状态行(status line), 6个首部行(header line), 然后是实体体(entity body).
状态行:

  • 第一个字段是协议版本
  • 第二个字段是状态码
  • 第三个字段是相应状态信息

首部行:

  • Connection: close. 告诉客户, 发送完报文后将关闭该TCP连接.
  • Date: 服务器产生并发送该相应报文的日期和时间. (是检索到对象, 插入到报文, 并发送该响应报文的时间)
  • Server: 类似于HTTP请求中的User-agent, 表明是什么服务器产生的.
  • Last-Modified: 对本地客户或者网络缓存服务器上的对象缓存有用.
  • Content-Length: 被发送对象中的字节数.
  • Content-Type: 对象类型.

那么用户是如何与服务器交互的呢?

这里就要用到cookie了, cookie技术有4个组件:

  • 在HTTP响应报文中的一个cookie首部行.
  • 在HTTP请求报文中的一个cookie首部行.
  • 在用户端系统中保留有一个cookie文件, 并由用户的浏览器进行管理
  • 位于Web站点的一个后端数据库

简单来说这种技术允许服务器追踪并记录这个客户, 因为客户端和服务端都遵循HTTP协议, 只要服务端设置了cookie, 而且这个cookie没有过有效期, 那么客户端每次访问对应的服务端都会携带这个cookie, 因此服务器就会知道你访问过哪些内容, 但此时服务器并不知道你是谁(只要你没登录或者没其它证明你身份的操作), 它只认得cookie, 只要cookie存的值足够特别, 服务器就能唯一标识这个用户. 而只有在你登录了服务器后服务器将cookie与你绑定, 它才知道你是谁.

尽管cookie能简化用户的互联网购物活动, 但是它的使用仍然有争议, 因为他们被认为是对用户隐私的一种侵害. 比如结合cookie和用户提供的账户信息, Web站点可以知道很多用户的信息, 并且可能将这些信息卖给第三方. cookie也分为第一方cookie与第三方cookie等, 这就涉及到定向广告相关的内容了.

Web缓存器(Web cache)也叫代理服务器(proxy server), 它可以大大减少客户对请求的响应时间, 特别是客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽.

通过内容分发网络(Content Distribution Network, CDN), Web缓存器在因特网中发挥着越来越重要的作用.
Web缓存器给初始服务器发送的条件GET方法(conditional GET)的首部行包含一个” If-Modified -Since :”, 如果资源对象没有被修改那么返回空对象的响应, 否则返回修改后的对象和日期. 它给判断缓存中的内容是否是陈旧的行为提高了效率.

2.2.2 文件传输协议:FTP

FTP使用了两个并行的TCP连接来传输文件:

  • 控制连接(control connection): 用于两主机之间传输控制信息, 如用户标识, 口令, 改变远程目录的命令以及存放(put)和获取(get)命令等.
  • 数据连接(data connection): 实际用于发送一个文件.

因为FTP协议使用一个独立的TCP控制连接, 所以我们也称FTP的控制信息是带外(out-of-band)传送的. 而HTTP协议在传输文件的同一个TCP连接中发送请求和响应首部行的, 因此可以说是带内(in-band)发送控制信息的.

当用户主机与远程主机开始一个FTP会话时, FTP客户端首先在21端口与服务器端发起一个用于控制的TCP连接. 当FTP服务端从控制连接中接收到一个文件传输命令后, 服务端便向客户端发起一个TCP数据连接传输数据然后关闭连接. 所以在一个会话期间, 用户还需要传输另一个文件, FTP则要打开另一个数据连接. FTP必须在整个会话期间保留用户的状态(state), 把特定的用户账户与连接联系起来, 对每一个用户会话状态信息进行追踪, 这限制了FTP同时维持的会话数.

2.2.3 因特网中的电子邮件

// TODO

2.2.4 DNS: 因特网的目录服务

DNS能提供主机名(hosename)转换成IP地址(IP address)的目录服务, 这就是域名系统(Domain Name System, DNS)的主要任务. 它是:

  • 由分层的DNS服务器(DNS server)实现的分布式数据库
  • 一个使得主机能查询分布式数据库的应用层协议, DNS协议使用53端口运行在UDP上

它不直接与用户打交道, 而是为因特网上的用户应用程序以及其他软件提供一种核心功能, 就是将主机名转换为IP地址.
它还提供一些重要的服务:

  • 主机别名(host aliasing): 有复杂主机名的主机能够拥有一个或者多个别名. 比如一台名为relay1.west-coast.enterprise.com的主机, 可能还有两个别名为enterprise.com和www.enterprise.com. 在这种情况下relay1.west-coast.enterprise.com也称为规范主机名(canonical hostname). 主机别名比规范主机名更容易记忆. 应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址.
  • 邮件服务器别名(mail server aliasing): MX记录(后面介绍)允许一个公司的邮件服务器和Web服务器使用相同(别名化)的主机名.
  • 负载均衡(load distribution): 一些繁忙的站点它可能有很多台服务器来冗余该站点, 所以这些冗余的服务器每一台都有不同的IP地址, 而DNS数据库中能存储这些IP地址的集合, 当用户请求某个主机别名时, DNS服务器从数据库拿出的IP集合中选取一条返回.

大致来说有三种DNS服务器: 根DNS服务器(Root DNS Server), 顶级域DNS服务器(Top-Level Domain, TLD DNS Server), 权威DNS服务器(Authoritative DNS Server).

它们的层次结构如下:

如果DNS客户要决定主机名 www.someexp.com 的IP地址, 用户首先和根服务器之一联系, 它返回顶级域名com的TLD服务器的IP地址, 然后客户与这些TLD服务器之一联系, 它将为 someexp.com 返回权威服务器地址的IP, 最后客户与 someexp.com 权威服务器之一联系, 它为主机名 www.someexp.com 返回其IP地址. 得到IP地址后客户就能带着IP地址访问相关的服务了. 细看一下这三种类型的DNS服务器:

  • 根DNS服务器(Root DNS Server): 在因特网上有13个根DNS服务器, 但每台”服务器”实际上是一个冗余服务器的网络, 到了2011年秋季共有247个根服务器.
  • 顶级域DNS服务器(Top-Level Domain, TLD DNS Server): 这些服务器负责顶级域名如com, org, net, edu和gov, 以及所有国家的顶级域名如cn, uk, fr, ca和jp等.
  • 权威DNS服务器(Authoritative DNS Server): 该服务器用来存储一些DNS记录, DNS记录能将主机名映射为IP地址. 一个组织机构能够实现它自己的权威DNS服务器来保存这些记录. 当然这些组织机构也能支付费用, 让一些记录存储在别的服务提供商的权威DNS服务器中. 多数大学和大公司实现和维护他们自己基本和辅助(备份)的DNS服务器.

还有另一类重要的DNS称为本地DNS服务器(local DNS server). 每个ISP(如一个大学, 一个系, 一个公司或居民区ISP)都有一台本地DNS服务器. 当主机与某个ISP连接时, 该ISP提供一台主机的IP地址, 这个主机具有一台或者多台其本地DNS服务器的IP地址(通过DHCP, 会在后面讲到), 然后你就能得到DNS服务器地址. 当主机发出DNS请求时, 该请求会被发往本地DNS服务器, 它起着代理的作用, 并将请求转发到DNS服务器结构层次中.

例子:
假设主机cis.poly.edu想知道主机gaia.cs.umass.edu的IP地址, 假设理工大学(Polytechnic)的本地DNS服务器为dns.poly.edu, 并且gaia.cs.umass.edu的权威DNS服务器为dns.umass.edu. 如下图:

    1. 请求主机cis.poly.edu首先向本地DNS服务器发送DNS查询报文, 报文含有被转换的主机名gaia.cs.umass.edu.
    1. 本地DNS服务器将该报文转发到根DNS服务器.
    1. 根服务器根据edu前缀向本地DNS服务器返回负责edu的TLD的IP地址列表.
    1. 本地DNS服务器向这些TLD服务器之一发送查询报文.
    1. TLD服务器注意到umass.edu前缀, 并返回权威DNS服务器的IP地址, 这个权威DNS服务器负责马赛诸塞大学的dns.umass.edu.
    1. 本地DNS服务器向dns.umass.edu发查询报文.
    1. dns.umass.edu用gaia.cs.umass.edu的IP地址进行响应.
    1. 本地服务器再把详情转发回请求主机.

上面为了获得一台主机名的映射, 发送了8份DNS报文, 4份查询4份响应. 而在实际场景中为了改善时延性能并减少在因特网上到处传输的DNS报文数量, DNS广泛使用了缓存技术, 也就是DNS缓存(DNS caching), 比方说上面的例子中的本地DNS服务器会缓存响应的信息. 例子假设了TLD服务器知道了目标主机的权威DNS服务器的IP地址, 一般而言这并不总是正确的. 相反, TLD服务器只是知道目标主机到TLD服务器之间的其中某个权威DNS服务器(这个前提是有多个权威DNS服务器). 在例子中我们可以假设该大学的DNS服务器下还有根据院系分开的DNS服务器, 那么假设目标主机以cs.umass.edu结尾, 也就是计算机系下的一个主机, 那么在这种情况下:

    1. 本地DNS服务器向dns.umass.edu发查询报文(报文的主机名为cs.umass.edu结尾).
    1. dns.umass.edu返回权威服务器cs.umass.edu的地址.
    1. 本地DNS服务器向cs.umass.edu发查询报文.
    1. cs.umass.edu用gaia.cs.umass.edu的IP地址进行响应.
    1. 本地服务器再把详情转发回请求主机.

在这个例子中共发送了10份DNS报文! 在这些例子中利用到了递归查询(recursive query)和迭代查询(iterative query). 理论上任何DNS查询向上面的例子一样既可以是迭代的也能是递归的. 下图展示了两种查询的区别:

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record, RR), RR提供了主机名到IP地址的映射. 每个DNS回答报文包含了一个或多条资源记录.
资源记录是一个包含了下列字段的4元组:
(Name, Value, Type, TTL)
而TTL是记录的生存时间, 也就是决定了资源记录应当从缓存中删除的时间, 下面就忽略TTL. 而Name和Value的值取决于Type:

  • 如果Type = A, 则Name是主机名, Value是该主机名对应的IP地址. 这是一条提供了标准的主机名到IP地址的映射. 例如(relay1.bar.foo.com, 145.37.93.126, A)就是一条类型A记录.
  • 如果Type = NS, 则Name是一个域(如foo.com), 而Value是一个知道如何获得该域中主机IP地址的权威DNS服务器的主机名. 这个记录用于沿着查询链路来路由DNS查询. 例如(foo.com, dns.foo.com, NS)就是一条类型为NS的记录.
  • 如果Type = CNAME, 则Name是一个别名, Value是别名为Name的主机对应的规范主机名. 该记录能够向查询的主机提供一个主机名对应的规范主机名. 例如(foo.com, relay1.bar.foo.com, CNAME)就是一条类型为CNAME的记录.
  • 如果Type = MX, 则Name是一个别名, 而Value为该别名的邮件服务器的规范主机名. 举例来说(foo.com, mail.bar.foo.com, MX)就是一条MX记录. 通过MX记录, 公司的邮件服务器和其他服务器可以使用相同的别名, 为了获得邮件服务器的规范主机名, DNS客户应当请求一条MX记录, 而为了获得其他服务器的规范主机名, DNS客户应当请求CNAME记录.

DNS的查询和回答报文有着相同的格式, 其字段语义什么的就不在这里说了.

文章配套有两个使用Python的套接字编程练习, 分别是UDP和TCP的, 两者的区别就是UDP每次向服务端发送消息都需要显示指明目标套接字的IP地址和端口, 而TCP建立了连接之后就不需要显示指明, 我自己对着改了的代码在这里.

3. 运输层

3.1 运输层概述

运输层协议是在端系统中而不是在路由器中实现的. 这一层的UDP和TCP最基本的职责是将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程间的交付服务. 这种扩展被称为运输层的多路复用多路分解. 而这两个协议有所不同:

  • UDP: 和IP服务一样, 它提供尽力而为交付服务, 它不能保证数据到达的完整性, 所以也被称为不可靠服务.
  • TCP: 首先它通过使用流量控制, 序号, 确认和定时器, 将数据正确地, 按序地交付给接收进程. 它提供可靠数据传输, 且还格外提供拥塞控制.

3.2 多路复用与多路分解

运输层是怎么实现进程间的交付的呢? 其实是运输层将传递的数据传递给对应的套接字, 然后应用层的进程会有一个或多个套接字. 套接字是运输层和应用层之间的桥梁. 我们通过浏览器访问网页: 首先客户端浏览器进程在给服务器发送HTTP请求前, 会在系统随机开一个端口(下图的1080端口), 程序通过Socket来发送或接受请求. 如下图:
// FIXME 这个图有点问题, 比如说那个ip不应该出现在这两层中间, 只是端口才出现

  • 多路分解↑: 简单来说就是运输层接收来自网络层的报文段, 然后将它分解交付到正确的套接字上.
  • 多路复用↓: 运输层从不同套接字中收集数据, 并为每个数据封装上首部信息(这些信息被目的主机用于分解), 然后将生成的报文段传递到网络层.

需要注意的是, 一个UDP套接字是由一个二元组(目的IP:目的port)来全面标识的. 而一个TCP套接字是四元组(源IP:源port + 目的IP:目的port), 因此TCP能通过四元组确定唯一一条连接, 所以也可以说是面向连接的.

3.3 UDP

UDP只是做了运输协议能够做的最少工作, 除了复用/分解功能以及少量的差错检测外, 它几乎没有对网络层的IP添加别的东西.
它对比TCP有如下优点:

  • 因为容忍丢失, 所以实时性较好(也就是就算丢包了, 不发也无所谓, 而TCP要求直到收到为止).
  • 无需连接建立(它没有TCP开始传输数据之前的三次握手).
  • 无连接状态信息(TCP为了实现可靠传输与拥塞控制, 它需要维护一些连接的状态信息, 比如发送缓存, 拥塞控制参数以及序号与确认号参数等).
  • 分组首部开销小(TCP报文段有20字节的首部开销, 而UDP只有8字节(32比特))

UDP报文段的首部只有4个字段, 每个字段由两个字节组成:

  • 源端口号
  • 目的端口号
  • 长度: 首部加数据的字节数
  • 校验和: 发送方将前三个字段相加后进行反码作为校验和, 接收方对前三个字段和校验和相加, 如果出现0就是分组出现差错.

但UDP的差错检测对差错没有恢复能力, 所以对于受损的报文段只能选择丢弃. 其他实现是将报文段交给应用程序并发出警告.

3.4 可靠数据传输原理

这一节作者没讲TCP噢, 就是带你一步一步走, 如何构建一套可靠传输协议(reliable data transfer protocol), 但问题是该协议下一层也许是不可靠的, 作者讲的一些做法, 在TCP协议中也有体现.

3.5 TCP

这一节依赖于上一节可靠数据传输原理, 比如它包括差错检测, 重传, 累积确认, 定时器以及用于序号和确认号的首部字段.

4. 网络层

4.1 概述

在网络中的每一台主机和路由器中都有一个网络层部分.

  • 转发(forwarding): 分组在单一的路由器中从一条入链路到一条出链路的传达.
  • 路由选择(routing): 涉及一个网络的所有路由器, 经过路由选择协议的共同交互, 来决定分组从源到目的地结点所采用的路径.

5. 链路层

协议

IP协议

这里说的IP协议是指Internet Protocol互联网协议, 而我们日常说得IP其实是指IP地址, 也就是一段数字. 在上面快递的例子中, IP地址相当于快递所在网点的地址, 那么在计算机网络中也是一样的, 接入互联网的设备每一台都会有一个IP地址. 在我们日常生活中, 家里办了宽带, 我们的设备能上网, 而那个宽带就包含运营商给我们提供的IP地址, 有了IP地址我们才能和互联网上其他设备进行通讯.

DNS协议

接入到网络的计算机都会有一个IP, 有的计算机是专门给其他计算机提供服务的, 也叫服务器, 所以服务器肯定有自己的IP, 但是用户直接通过IP来访问对应服务器是不大方便的, 所以就有了域名, 而DNS协议的作用就是将域名解析成IP, 但是域名对应的IP经常在变化, 所以就需要专门将域名解析成IP的DNS服务器. 我们直接访问的DNS服务器叫本地DNS服务器, 它本身没有域名和IP对应关系, 在我们发出请求时它会从主DNS服务器获取然后保存到缓存中.

TCP/IP协议

TCP协议和IP协议是两个不同的协议, TCP协议用来规范传输规则, 而IP协议只是负责找到地址. TCP协议在传输前会进行”三次握手”, 传输完数据断开时要进行”四次挥手”.

TCP协议

TCP协议是一套规则, 如果两台计算机都遵循这个规则, 那么它们之间就可以建立一种可靠的连接, 这种可靠的连接是连接双方都遵循这个TCP协议才能建立的, 而遵守这套协议能够保证我们双方发送和接收到的消息有序且完整.
协议的特点:

  • 面向连接, 可靠的字节流服务
  • 一个TCP连接中只有两方进行通信, 广播和多播不能用于TCP
  • 使用校验和, 确认和重传机制来保证可靠的传输
  • 数据分节排序, 使用累积确认保证数据顺序不变和非重复
  • 使用滑动窗口机制实现流量控制, 通过动态改变窗口大小进行拥塞控制
  • TCP也不是100%可靠的协议, 如果有可能就把数据送到接收方, 否则就放弃重传中断连接通知用户.

如何建立TCP连接?

现在计算机双方都知道我需要遵循TCP协议这个规则, 我就能跟其他也遵循这个规则的计算机通讯了, 但是我如何跟另外的TA建立连接呢?

IP协议

参考: