计算机网络与通信笔记(二)

站内地址

计算机网络与通信笔记

点击下载计算机网络与通信笔记PDF版

二、应用层

2.1 应用层协议原理

2.1.1 进程通信

• 客户与服务器进程

  • 网络应用程序运行后，就变成了网络应用进程

  • 两个在不同端系统的进程，通过跨越计算机网络交换报文而相互通信

  • 网络应用程序由成对进程组成，在一对进程的通信会话场景中，发起通信的进程称为客户，等待联系的进程称为服务器

• 进程与计算机网络的接口

  • 进程通过一个称为套接字$(Socket)$的软件接口向网络发送报文和从网络接收报文
  • 套接字是同一台主机内应用层与运输层的接口，也成为应用程序和网络之间的应用程序编程窗口

• 进程寻址

  • 为了与目的主机上进程的通信，需要定义目的主机的地址和目的主机中指定接收进程的标识符
  • 目的主机地址由$32$位的$IP$地址标识
  • 目的进程地址由$16$位目的地端口号$Port\enspace Number$标识，如$Web$服务器的端口号为$80$，$SMTP$的端口号为$25$
  • 套接字长度为$48$位

2.1.2 运输服务简介

• $TCP$服务

  • 面向连接：在报文流动前，$TCP$让客户和服务器互相交换运输层控制信息以为分组运输做好准备（握手），此时，一个$TCP$连接在两个进程的套接字直接建立
  • 可靠性：无差错、无字节丢失与冗余、顺序地传输分组
  • 拥塞控制机制：当网络拥塞时，抑制发送进程
  • 不提供加密机制

• $UDP$服务

  • 没有握手过程
  • 不可靠数据传送服务
  • 没有拥塞控制机制
  • 不提供加密机制

• $SSL$安全套接字层

  • 提供加密的$TCP$连接
  • 提供数据完整性和端点鉴别

• 应用层协议与支撑的运输层协议

应用	应用层协议	支撑的运输层协议
电子邮件	$SMTP$	$TCP$
远程终端访问	$Telnet$	$TCP$
$Web$、流式多媒体	$HTTP$	$TCP$
文件传输	$FTP$	$TCP$
因特网电话	$SIP$、$RTP$	$UDP$或$TCP$

2.2 $Web$和$HTTP$

2.2.1 $HTTP$概述

• 相关概念

  • $HTTP$全称为超文本传输协议$(HyperText\enspace Transfer\enspace Protocol)$

  • $Web$页面由对象组成，如$HTML$文件，$JPEG$图像

  • 通过$URL$地址引用对象，$URL$地址由存放对象的服务器地址和对象的路径组成

    如对于$URL$地址http://cloudchewie.com/index.html：

    $cloudchewie.com$为主机名，$/index.html$为对象路径

  • $Web\enspace Browser$实现了$HTTP$的客户端，$Web\enspace Server$实现了$HTTP$的服务端，用于存储$Web$对象，每个对象由$URL$路径访问，因此$Web$是典型的$C/S$模式

  • $HTTP$负责定义客户向服务器请求$Web$页面的方式以及服务器向客户返回$Web$页面的方式，其传递的报文称为$HTTP$报文

  • 客户向其套接字接口发送$HTTP$请求报文并从其套接字接口接收$HTTP$响应报文；当客户发送报文后，该报文即脱离客户控制而进入$TCP$控制，从而使得应用层协议$HTTP$无需关心报文丢失和运输层的实现细节

  • $HTTP$服务器不保存关于客户的任何信息，是一个无状态协议

• 非持续连接

  • 每个$TCP$连接只传输一个请求报文和一个响应报文

  • 当客户接收$HTTP$响应报文后，$TCP$连接关闭

  • 如果需要继续发送请求，需要建立全新的$TCP$连接

  • 可以使用并行的连接改善缩短响应时间

    $TCP$服务是建立在连接之上的，每次建立连接前，都需要进行三次握手过程，如下图所示：

    

    1. 客户端向服务器发送一个小的$TCP$报文段
    2. 服务器用一个小的$TCP$报文段进行确认和响应
    3. 客户向服务器返回确认并发送$HTTP$请求报文
    4. 在这之后，服务器开始发送文件到客户

    其中，环节$1-2$占用了一个往返时间$RTT$，环节$3-4$占用了一个往返时间$RTT$并且耗费了传输文件的时间

    因此，在非持续连接的HTTP下，每传送一个对象，就需要经受两个RTT的交付时延

• 持续连接

  • 服务器发送$HTTP$响应报文后保持$TCP$连接，使得客户的后续请求继续使用该连接进行传送
  • 当该连接经过一定时间间隔（可配置的超时间隔）仍未使用，其服务器就将关闭该连接

2.2.2 $HTTP$报文

• $HTTP$请求报文（在线交互程序）

  #典型的HTTP请求报文
  GET /index.html HTTP/1.1\r\n
  Host: www-net.cs.umass.edu\r\n
  User-Agent: Mozilla/5.0\r\n
  Accept: text/html,application/xhtml+xml\r\n
  Accept-Language: en-us,en;q=0.5\r\n
  Accept-Encoding: gzip,deflate\r\n
  Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
  Keep-Alive: 115\r\n
  Connection: keep-alive\r\n
  \r\n

  • 请求报文的第一行称为请求行，包括方法字段、$URL$字段、$HTTP$版本字段

方法字段	主要作用
$GET$	向服务器请求指定$URL$的对象
$POST$	用于向服务器提交表单数据也可以同时请求一个$Web$页面
$DELETE$	返回响应报文，不包含请求的对象
$PUT$	上传的文件放在实体主体字段中，目标路径由$URL$字段标明
$HEAD$	删除$URL$字段中指定的文件

• 其余行称为首部行

  • $Host$指明了对象所在的主机
  • $Connection$指明非持续连接$(Close)$和持续连接$(keep-alive)$
  • $Keep-Alive$指明持续连接的超时间隔
  • $User-agent$指明用户浏览器类型，有助于服务器根据不同的用户代理发送相同对象的不同版本
  • $Accept-*$指用户想要得到特定语言、编码格式、字符集的该对象

• 结尾单独一行回车、换行表示报文首部结束

• 实体体，在首部行之后的请求体

  • 当发送$GET$请求时，实体体为空；
  • 当用户填写表单并发送$POST$请求时，实体体即为用户填写的表单；
  • 当用户填写表单时，也可以使用$GET$方法，如/learning/search?key=banana&lang=zh

• $HTTP$请求报文的通用格式

  

• $HTTP$响应报文（在线交互程序）

  #典型的HTTP响应报文
  HTTP/1.1 200 OK\r\n
  Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
  Server: Apache/2.0.52 (CentOS)\r\n
  Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
  ETag: "17dc6-a5c-bf716880"\r\n
  Accept-Ranges: bytes\r\n
  Content-Length: 2652\r\n
  Keep-Alive: timeout=10, max=100\r\n
  Connection: Keep-Alive\r\n
  Content-Type: text/html; charset=ISO-8859-1\r\n
  \r\n
  data data data data data ...

  • 响应报文的第一行称为初始状态行，包括协议版本字段、状态码、状态信息

状态码	状态信息	说明
$200$	$OK$	请求成功
$301$	$Moved\enspace Permanently$	请求的对象被永久转移，新的$URL$定义在$Location$首部行
$400$	$Bad\enspace Request$	通用差错代码，请求不能被服务器理解
$404$	$Not\enspace Found$	被请求的对象不在服务器
$500$	$HTTP\enspace Version\enspace Not\enspace Supported$	服务器不支持请求报文中的$HTTP$协议版本

• 其余行称为首部行

  • $Date$指示服务器发送响应报文的日期时间
  • $Server$指示服务器类型，类似于请求报文中的$User-agent$
  • $Last\enspace Modified$指示对象创建或最后修改的日期时间
  • $Content-Length$指示被发送对象的字节数
  • $Content-Type$指示实体体中对象为$HTML$文本

• 实体体包含被请求的对象

• $HTTP$响应报文的通用格式

2.2.3 $Cookie$

• $Cookie$的意义
  • 限制用户的访问
  • 将内容与用户身份相关联
  • 在无状态的$HTTP$上建立用户会话层
• $Cookie$的组成
  • $HTTP$响应报文中的$Cookie$首部行
  • $HTTP$请求报文中的$Cookie$首部行
  • 端系统中保留$Cookie$文件
  • $Web$服务器的$Cookie$数据库
• $Cookie$的使用
  • 客户向服务器发送普通请求报文
  • 服务器为客户创建$ID$如U202073245并放置在响应报文的首部行
  • 客户存储$Cookie$
  • 客户将$Cookie$放置在请求报文的首部行
  • 服务器根据$Cookie$采取指定动作，并返回普通响应报文

2.3 电子邮件

2.3.1 电子邮件系统的构成

• 用户代理
  • 用户可以撰写编辑邮件、查看邮件
  • 如网易邮箱大师、$FoxMail$
• 邮件服务器
  • 存储用户邮件的服务器
  • 在报文队列中维护需要发送的邮件报文
• 简单邮件传输协议$SMTP$
  • 将邮件从发送方的客户端发送到发送方的邮件服务器
  • 将邮件从发送方的邮件服务器发送到接收方的邮件服务器

2.3.2 $SMTP$协议

• 基本介绍（在线交互程序）

  • 使用$TCP$运输协议进行可靠的邮件传送，端口号为$25$
  • 不使用中间邮件服务器发送邮件，而是直接在发送方服务器和接收方服务器间进行传输
  • 使用持续连接
  • 要求报文（首部和信体）全部使用$ 7-bit\enspace ASCII$码
  • $SMTP$服务器用$CRLF.CRLF $表示邮件报文的结束
  

• 报文格式

  From: alice@qq.com
  To: Bob@google.com
  Subject: Searching for the meaning of life.

• 与$HTTP$协议的对比

	$HTTP$	$SMTP$
协议类型	拉协议	推协议
报文编码格式	不限制	$ 7-bit\enspace ASCII$
多对象	每个对象分装在各自的响应报文中	多个对象在多分部的报文中

• 使用$telnet$指令访问$QQ$邮箱

  telnet smtp.qq.com 25
  auth login
  base64-mail
  base64-authentication-code
  helo qq.com
  mail from:<xxx@xx.xx>
  rcpt to:<xxx@xx.xx>
  data
  Hello World!
  Hello World!
  .
  quit

2.3.3 $POP3$协议

• 运行在端口$110$的邮件访问协议

• 运行方式

  • 特许阶段：用户代理发送用户名和口令以鉴别用户

    主要命令：user 和pass

    服务器的响应回答有$+OK$、$-ERR$

  • 事务处理阶段：用户代理取回报文，同时可以对报文做删除标记的更改，获取邮件统计信息

    $list$——列出报文号码

    $retr$——用报文号码取回报文

    $dele$——用报文号码删除邮件

  • 更新阶段

    $quit$——结束$POP3$会话，服务器删除被标记为删除的邮件

• 使用$telnet$指令访问$QQ$邮箱

  telnet pop.qq.com 110
  user QQ-ID
  pass authentication-code
  list
  retr 1
  dele 1
  quit

2.3.4 $IMAP$协议

• 允许用户在服务器上组织自己的邮件目录

• 维护$IMAP$会话的用户信息：目录名以及报文$ID$与目录名之间的映射关系

• 使用$telnet$指令访问$QQ$邮箱

  telnet imap.qq.com 143
  a01 login QQ-ID authentication-code
  a02 list "" *
  a03 select inbox
  a04 create folder
  a05 delete folder
  a06 rename oldfolder new folder

2.4 $DNS$

2.4.1 $DNS$服务

• $DNS$简况（在线交互程序）
  • $DNS$能够将主机名解析为主机的$IP$地址
  • $DNS$是一个分布式数据库，由很多$DNS$服务器按照层次结构组织
  • $DNS$运行在端到端系统上，且使用$UDP$协议（$53$号端口）进行报文传输
• $DNS$解析过程
  • 用户请求$URL$http://cloudchewie.com/index.html
  • 浏览器抽取出主机名cloudchewie.com并发送给$DNS$客户端
  • $DNS$客户端向$DNS$服务器发送查询请求报文
  • $DNS$服务器返回包含主机名对应$IP$地址的响应报文
  • $DNS$客户端将$IP$地址传送给浏览器
  • 浏览器向$IP$地址所在$Web$服务器发起$TCP$连接
• 其他服务
  • 主机别名：获取主机别名对应的主机规范名
  • 邮件服务器别名：获取邮件服务器主机别名对应的主机规范名
  • 负载分配：将一个$IP$地址集合与同一个规范主机名相联系

2.4.2 $DNS$工作机理

• 采用单台$DNS$服务器

  • 单点故障：一旦崩溃，因特网瘫痪
  • 通信容量：该台服务器不得不处理所有$HTTP$请求报文和电子邮件报文
  • 时延严重：集中式数据库将造成严重的拥塞与时延
  • 难以维护：不得不持续更新以适应数据更改

• 采用分布式层次化数据库

  
  • 根服务器提供$TLD$服务器的$IP$地址
  • $TLD$服务器提供权威服务器的$IP$地址，负责所有顶级域名和所有国家顶级域
  • 权威服务器提供域名到$IP$地址的映射服务
  • 本地$DNS$服务器（默认$DNS$服务器）
    • 当一台主机需要做一个域名查询的时候，查询请求首先被发送到本地域名服务器

• 递归查询与迭代查询（在线交互程序）

• $DNS$缓存（在线交互程序）

  • 一旦 (任何) 域名服务器得知了某个映射, 就将其缓存
  • 在一定的时间间隔后缓存的条目将会过期（自动消除）
  • $TLD$服务器的地址通常被缓存在本地$DNS$服务器中，以减少根服务器负载

2.4.3 $DNS$记录

格式为四元组$(Name,Value,Type,TTL)$，其中$TTL$表示记录的生存时间

$Type$	$Name$	$Value$
$A$	主机名	$IP$地址
$CNAME$	主机别名	规范主机名
$NS$	域	该域权威域名服务器的主机名
$MX$	邮件服务器的主机别名	邮件服务器的规范主机名

#使用nslookup进行DNS解析
#进入交互模式
nslookup
server www.net.cn
server dns.hust.edu.cn
set ty=A
cloudchewie.com
hust.edu.cn
set ty=ns
cloudchewie.com
set ty=cname
cloudchewie.com
set ty=mx
hust.edu.com