前言:本系列是基于《计算机网络:自顶向下方法》的学习笔记,整理了部分网络的资料,主要以个人学习记忆为主,欢迎大家共同探讨!
在现代网络应用程序中使用的两种主流体系结构:
1、客户端-服务器体系结构
在客户-服务器体系结构( client- server architecture)中,有一个总是打开的主机称为服务器,它服务于来自许多其他称为客户的主机的请求。一个典型的例子是Web应用程序,其中Web服务器服务于来自浏览器的请求。当Web服务器接收到来自某客户对某对象的请求时,它向该客户发送所请求的对象作为响应。
应用:WEB,FTP,电子邮件,Telnet
tips:客户(如web中的浏览器)相互之间不直接通信;服务器具有固定的、周知的ip地址。
2、P2P体系结构(对等结构)
在一个P2P体系结构(P2P architecture)中,对位于数据中心的专用服务器有最小的(或者没有)依赖。相反,应用程序在间断连接的主机对之间使用直接通信,这些主机对被称为对等方。
应用:迅雷,因特网电话,视频会议
tips:客户机间的直接通信使得P2P有了强大的自扩展性(self-calability),尽管每个对等方都由于请求文件产生工作负载,但每个对等方通过向其他对等方分发文件也为系统增加服务能力
网络应用程序由成对的进程组成,在两个不同端系统上的进程,通过跨越计算机网络交换报文(message)。通常将两个进程之一标识为客户(发起通信的进程),另一个标识为服务器(等待联系的进程)。
套接字:应用程序编程接口
进程之间的报文交换必须通过下面的网络(即传输层)。进程通过一个称为套接字(socket)的软件接口向网络发送报文和从网络接收报文,如下图所示:
总结:套接字是应用程序进程和运输层协议之间的接口,通过套接字发送和接受报文。
因特网(TCP/IP网络)为应用程序提供了两个运输层协议,即UDP和TCP:
1、TCP服务
TCP协议则实现了“流”形式的通信,实现的是端口到端口(port)的通信。
①面向连接服务:
在应用层数据报文开始流动之前,TCP让客户和服务器互相交换运输层控制信息,即握手阶段。之后,一条全双工的TCP连接就在两个进程的套接字之间建立了。应用程序结束发送报文时,经历终止协议,即挥手阶段,则拆除该连接。
②可靠的数据传送服务:
通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。
③拥塞控制机制:
当发送方和接收方之间的网络出现拥塞时,TCP 的拥塞控制机制会抑制发送进程。TCP 拥塞控制机制也试图限制每个 TCP 连接,使他们达到公平共享网络带宽的目的。
2、UDP服务
UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。
①面向无连接:
UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的,不会对数据报文进行任何拆分和拼接操作。
在发送端,应用层通过套接字将数据传递给传输层的 UDP 协议,UDP 只会给数据增加一个 UDP 头标识;在接收端,网络层将数据传递给传输层,UDP 只去除 IP 报文头就传递给应用层。
②不可靠数据传送服务:
当进程将一个报文发送进 UDP 套接字时,UDP并不保证该报文到达接收进程。不仅如此,到达接收进程的报文也可能是乱序到达的。
此外, UDP 因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包。
总结:
运输协议 | UDP | TCP |
---|---|---|
是否连接 | 无连接 | 面向连接 |
是否可靠 | 不可靠传输 | 可靠传输 |
连接对象个数 | 支持一对一,一对多,多对一和多对多通信 | 一对一 |
是否连接 | 无连接 | 面向连接 |
传输速度 | 快 | 慢 |
适用场景 | 实时应用(视频会议、直播等) | 可靠传输(文件) |
应用层协议定义了运行在不同端系统上的应用程式进程如何相互传递报文
定义:
1、交换报文的类型,例如请求报文和响应报文。
2、各种报文类型的语法,如报文中各个字段及这些字段是如何描述的。
3、字段的语义,即这些字段中包含的信息的含义。
4、一个进程何时以及如何发送报文,对报文进行响应的规划。
应用层协议只是网络应用的一个部分,比如一个Web应用包括文档格式的标准(HTML)、浏览器(firefox、chrome等)、服务器以及一个应用层协议(HTTP)。又比如一个电子邮件应用包括邮件服务器、客户端程序、定义电子邮件报文结构的标准、定义报文传递的应用层协议和定义如何对报文首部进行解释的应用层协议。用于电子邮件的主要应用层协议是SMTP。
Web的应用层协议是超文本传输协议( HyperText Transfer Protocol, HTTP), HTTP由两个程序实现:一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中,通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。
1、支撑运输协议:
TCP协议(非UDP)
2、交互方式:
HTTP 客户首先发起一个与服务器的TCP连接。一旦连接建立,该浏览器和服务器进程就可以通过套接字接口访问TCP。
客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。类似地,服务器从它的套接字接口接收HTTP请求报文和向它的套接字接口发送HTTP响应报文。
TCP为HTTP提供可靠数据传输服务。这意味着,一个客户进程发出的每个HTTP请求报文最终能完整地到达服务器;类似地,服务器进程发出的每个HTTP响应报文最终能完整地到达客户。这里我们看到了分层体系结构最大的优点,即HTTP协议不用担心数据丢失,也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。
tips:HTTP是无状态协议,服务器向客户发送被请求的文件,而不存储任何该客户的状态信息。
非持续连接( non- persistent connection):每个请求/响应对是经一个单独的TCP连接发送。
持续连接( persistent connection):所有的请求及其响应经相同的TCP连接发送。
tips:HTTP在其默认方式下使用持续连接,但也能配置成非持续连接
1、非持续连接
每个TCP连接在服务器发送一个对象后关闭,即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。假如该Web页面含有11个对象,则要产生11个TCP连接。
往返时间( Round-Trip Time, RTT) :该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。
当用户点击一个超链接时:
这引起刘览器在它和Web服务器之间发起一个TCP连接,这涉及一次“三次握手”过程,即客户向服务器发送一个小TCP报文段,服务器用一个小TCP报文段做出确认和响应,最后,客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个RTT。完成了三次握手的前两个部分后,客户结合三次握手的第三部分(确认)向该TCP连接发送一个HTTP请求报文。一旦该请求报文到达服务器,服务器就在该TCP连接.上发送HTML文件。该HTTP请求/响应用去了另一个RTT。因此,粗略地讲,总的响应时间就是两个RTT加上服务器传输HTML文件的时间。
2、持续连接
在采用持续连接的情况下,服务器再发送响应后保持该 TCP 连接打开。再相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。一般来说,如果一条连接经过一定的时间间隔(一个可配置的时间间隔)仍未被使用,HTTP 服务器就关闭该连接。
1、HTTP请求报文
GET /boyfriend/memory.html HTTP/1.1
Host: www.xinxin.org
Connection: close
User-agent: Chrome/57.0
Accept-language: ch
HTTP请求报文的第一行叫请求行(request line),其后的行叫首部行(header line)
①请求行:
请求行有三个字段:方法字段、URL字段和HTTP版本字段。方法字段包括:GET、POST、HEAD、PUT和DELETE。HEAD方法用于调试跟踪,PUT方法用于向服务器上传文件,DELETE方法用于删除服务器文件(绝大部分的HTTP请求用的都是GET)
②首部行:
Host: www.xinxin.org 指明了对象所在的主机。
Connection: close 要求服务器发送完请求的对象后就关闭该连接。
User-agent: Chrome/57.0 用来指明用户代理,即向服务器发送请求的浏览器的类型。
Accept-language: ch 指明了用户想要得到该对象的中文版本。
以下是一个HTTP请求报文的通用格式:
tips:实体体(Entity body),在使用 GET 方法时为空,使用 POST 方法提交表单时才使用到该实体体。当然,HTML表单也经常使用GET方法,在URL中包括输入的数据。
2、HTTP响应报文
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 ......)
响应报文分为三个部分:一个初始状态行(状态行有三个字段:版本协议字段、状态码和相应状态信息)、6个首部行和实体体。
HTTP是应用非常广泛的协议,我们每一天都在接触,同时天然具有跨平台的优越性。那么问题来了,那么为什么会有HTTPS的出现呢,是HTTP它不香吗?诚然,当今的互联网离不开HTTP,但是,HTTP其本身鲜明的特性,同样是一把双刃剑。
首先,HTTP通信使用不加密的明文,内容有可能会被窃听,比如账号信息容易泄露;其次HTTP不验证通信方的身份,因此有可能遭到伪装,比如访问假的淘宝;再者,HTTP无法证明报文的完整性,所以有可能已遭篡改,比如网页上的垃圾广告。
HTTP协议中的安全隐患,我们可以用HTTPS的方法解决——HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议。
SSL,即安全套接字层( Secure Sockets Layer, SSL)。 用SSL加强后的TCP不仅能够做传统的TCP所能做的一切,而且提供了关键的进程到进程的安全性服务,包括加密、数据完整性和端点鉴别。我们强调SSL不是与TCP和UDP在相同层次上的第三种因特网运输协议,而是一种对TCP的加强,这种强化是在应用层上实现的。
特点:
1、混合加密的方式实现信息的机密性,解决了窃听的风险。混合加密结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密,然后使用非对称加密的公钥再对秘钥进行加密,所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥,因此即使被黑客截取,由于没有私钥,无法获取到加密明文的秘钥,便无法获取到明文数据。
2、摘要算法的方式来实现完整性,它能够为数据生成独一无二的「指纹」,指纹用于校验数据的完整性,解决了篡改的风险。通过单向hash函数对原文进行哈希,将需加密的明文“摘要”成一串固定长度(如128bit)的密文,不同的明文摘要成的密文其结果总是不相同,同样的明文其摘要必定一致,并且即使知道了摘要也不能反推出明文。
3、将服务器公钥放入到数字证书中,解决了冒充的风险。
关键指标:
1、加密(Encryption), HTTPS 通过对数据加密来使其免受窃听者对数据的监听,这就意味着当用户在浏览网站时,没有人能够监听他和网站之间的信息交换,或者跟踪用户的活动,访问记录等,从而窃取用户信息。
2、数据一致性(Data integrity),数据在传输的过程中不会被窃听者所修改,用户发送的数据会完整的传输到服务端,保证用户发的是什么,服务器接收的就是什么。
3、身份认证(Authentication),是指确认对方的真实身份,也就是证明你是你(可以比作人脸识别),它可以防止中间人攻击并建立用户信任。
HTTP协议本身是无状态的,即服务器无法判断用户身份。Cookie实际上是一小段的文本信息(key-value格式)。客户端向服务器发起请求,如果服务器需要记录该用户状态,就使用response向客户端浏览器发送一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。(cookie在无状态的http之上建立了一个用户会话层)
cookie 有 4 个技术组件:
①在 HTTP 响应报文中的一个 cookie 首部行;
②在 HTTP 请求报文中的一个 cookie 首部行;
③在用户端系统中保留有一个 cookie 文件,并由用户的浏览器进行管理;
④位于 Web 站点的一个后端数据库
下图是cookie跟踪用户的流程(客户首次与amazon服务器联系,已经访问过ebay站点):
客户端发送一个请求到服务器—> 服务器发送一个HttpResponse响应到客户端,其中包含Set-Cookie的头部(含有识别码1678) —> 客户端保存cookie,之后向服务器发送请求时,HttpRequest请求中会包含一个Cookie的头部—> 服务器返回响应数据
Amazon会在其数据库中,将识别码和个人信息关联起来,所以在第二次登陆的时候,就不必重复输入个人信息(第一次已经输入过)
tips:Cookie是不可以跨域名的,隐私安全机制禁止网站非法获取其他网站的 Cookie。正常情况下,同一个一级域名下的两个二级域名也不能交互使用Cookie,比如 test1.mcrwayfun.com和 test2.mcrwayfun.com,因为二者的域名不完全相同。如果想要 mcrwayfun.com名下的二级域名都可以使用该Cookie,需要设置 Cookie的 domain参数为 .mcrwayfun.com,这样使用test1.mcrwayfun.com和 test2.mcrwayfun.com就能访问同一个 cookie。
Web缓存器( Web cache)也叫代理服务器(proxy server),它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自已的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本,可以配置用户的浏览器,使得用户的所有HTTP请求首先指向Web缓存器。一旦某浏览器被配置,每个对某对象的浏览器请求首先被定向到该Web缓存器。
当浏览器申请一个文件时,先建立一个到web缓存的TCP连接,如果缓存服务器上有这个文件就返回,否则,他就建立一个到原始服务器的TCP获得该文件并存储,之后将该文件发回客户端。web缓存可以大幅减少对客户端的响应时间,减少机构内部网络和internet之间的链路通信量并节约带宽。
条件get:
web缓存上的文件可能是陈旧的。为此HTTP引入了条件get,即web缓存在保存一个文件时会记录其最后修改时间,客户端每次请求文件时,web缓存会向原始服务器发送一个带有if-modified-since的报文,如果该文件没有改动就直接把缓存中的文件返回给用户,并且在服务器返回的相应报文中状态行为304 No Modified,否则重新下载该文件。
电子邮件系统有 3 个主要组成部分:用户代理、邮件服务器、简单邮件传输协议(SMTP)
下图是发送报文的过程:
为什么不能直接发送到对方的邮件服务器,而要分成两步呢?
主要是因为不通过Alice 的邮件服务器进行中继,Alice 的用户代理将没有任何办法到达一不可达的目的地接收服务器。通过首先将邮件存放在自己的邮件服务器中,Alice的邮件服务器可以重复地尝试向Bob的邮件服务器发送该报文,如每30分钟一次,直到Bob的邮件服务器变得运行为止。
1、SMTP协议
SMTP 是因特网中电子邮件中主要的应用层协议。它使用 TCP 可靠数据传输。SMTP 限制所有的邮件报文只能采用简单的 7 比特 ASCII 表示。
tips:SMTP 一般不使用中间服务器发送邮件,即使这两个邮件服务器位于地球的两端也一样;SMTP 用的是持续链接,如果发送邮件服务器有几个报文发往同一个接收邮件服务器,它可以通过同一个 TCP 连接发送所有的的报文。
2、与HTTP的对比
①HTTP主要是一个拉协议( pull protocol) ,即在方便的时候,某些人在Web服务器上装载信息,用户使用HTTP从该服务器拉取这些应用层信息。特别是TCP连接是由想接收文件的机器发起的。另一方面,SMTP 基本上是一个推协议( push protocol), 即发送邮件服务器把文件推向接收邮件服务器。特别是,这个TCP连接是由要发送该文件的机器发起的。
②SMTP要求每个报文( 包括它们的体)采用7比特ASCII码格式。如果某报文包含了非7比特ASCII字符( 如具有重音的法文字符)或二进制数据(如图形文件),则该报文必须按照7比特ASCII码进行编码。HTTP 数据则不受这种限制。
③处理一个既包含文本又包含图形(也可能是其他媒体类型)的文档:HTTP把每个对象封装到它自己的HTTP响应报文中,而SMTP则把所有报文对象放在一个报文之中。
3、邮件访问协议
邮件如何从接收方的服务器到达接收方主机上的用户代理?值得注意的是用户代理不能使用SMTP得到报文,因为取报文是一个拉操作,而SMTP协议是一个推协议。
通过引入邮件访问协议来解决这个问题,目前有一些流行的邮件访问协议,包括第三版的邮局协议( PostOffice Protocol- Version 3, POP3)、 因特网邮件访问协议( Intermet Mail Access Protocol ,IMAP)以及HTTP。
识别主机有两种方式,通过主机名或者IP地址。人们喜欢便于记忆的主机名标识方式,而路由器则喜欢定长的、有着层次结构的IP地址。为了折中这些不同的偏好,我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统( Domain Name System, DNS)的主要任务。
DNS是:
①一个由分层的DNS服务器(DNSserver)实现的分布式数据库;
②一个使得主机能够查询分布式数据库的应用层协议。
DNS协议运行在UDP之上,使用53号端口。
tips:除此之外,DNS还提供了一些重要的服务,包括主机别名、邮件服务器别名、负载分配等。
分布式、层次数据库:
为了处理扩展性问题,DNS使用了大量的DNS服务器,它们以层次方式组织,并且分布在全世界范围内。没有一台DNS服务器拥有因特网上所有主机的映射。相反,这些映射分布在所有的DNS服务器上。大致说来,有3种类型的DNS服务器:根DNS服务器、顶级域(Top- Level Domain, TLD) DNS 服务器和权威DNS服务器。这些服务器以下图所示的层次结构组织起来。
除此之外,还有另一类重要的DNS服务器,称为本地DNS服务器( local DNS server)。 当主机发出DNS请求时,该请求被发往本地DNS服务器,它起着代理的作用,并将该请求转发到DNS服务器层次结构中。
下图是一个DNS服务器次序交互的简单例子(主机cse.nyu.edu访问gaia.cs.umass.edu):
主要流程:
①本地DNS服务器将该报文转发到根DNS服务器;
②该根DNS服务器注意到其edu前缀,并向本地DNS服务器返回负责edu的TLD的IP地址列表;
③本地DNS服务器则再次向这些TLD服务器之一发送查询报文。
④该TLD服务器注意到umass.edu前缀,并用权威DNS服务器的IP地址进行响应,该权威DNS服务器是负责马萨诸塞大学的dns.umass.edu。
⑤本地DNS服务器直接向dns.umass.edu重发查询报文,并收到相应。
本例利用了递归查询( recursive query)、迭代查询( iterative query)。从cse. nyu. edu到dns. nyu. edu发出的查询是递归查询,因为该查询以自的名义请求dns.nyu.edu来获得该映射。而后继的3个查询是迭代查询,因为所有的回答都是直接返回给本地DNS服务器
tips:在本例中,为了获得一台主机名的映射,共发送了8份DNS报文: 4份查询报文和4份回答报文。假如TLD服务器只是知道中间的某个DNS服务器,并不知道用于主机的权威DNS服务器的IP地址,本例则需要10份DNS报文
与Web缓存器一样,DNS服务器同样有缓存器。实际上,为了改善时延性能并减少在因特网,上到处传输的DNS报文数量,DNS广泛使用了缓存技术。
DNS 缓存的原理非常简单。在一个请求链中,当某DNS服务器接收一个DNS回答(例如,包含某主机名到IP地址的映射)时,它能将映射缓存在本地存储器中。
因为有了缓存,该本地DNS服务器可以立即返回cnn. com的IP地址,而不必查询任何其他DNS服务器。本地DNS服务器也能够缓存TLD服务器的IP地址,因而允许本地DNS绕过查询链中的根DNS服务器。事实上,因为缓存,除了少数DNS查询以外,根服务器被绕过了。