TCPIP应用层协议.pptVIP

应用层 C/S模式 客户/服务器模式的特点 客户进程： 运行于客户机上，响应用户触发的事件,检查用户输入数据向服务器发送请求并接收服务器响应，进行数据通信； 服务器进程： 监听处理远程客户的请求, 向客户机发回结果； 一般都有操作数据库的功能； FTP：文件传输协议 从一台计算机中复制文件到另外一台远程计算机中的问题： 存储数据格式不同； 文件命名规定不同； 对于相同的功能，操作系统使用命令不同； 访问控制方法不同； FTP使用TCP可靠的传输服务提供文件传输，消除在不同操作系统下处理文件的不兼容性； 客户服务器方式； FTP服务器端 FTP的服务器进程由两大部分组成： 主进程－－只有一个，负责接收新的请求； 从属进程－－有若干个，负责处理单个请求； 主进程的工作步骤： 打开周知端口（21），使用户进程能够连接上； 等待客户进程发出连接请求； 启动从属进程来处理客户进程发来的请求； 从属进程对客户进程请求处理完毕后终止； 回到等待状态，继续接受其他客户进程发来的请求； FTP的两个连接 FTP客户和服务器之间要建立两个连接： 控制连接－－使用端口21，在整个会话期间一直保持打开，FTP客户所发出的传送请求通过控制连接发送给控制进程； 数据连接－－使用端口20，控制进程在收到FTP客户发来的文件传输请求后就创建一个数据连接，完成文件的传送，传送完毕后关闭数据连接； 万维网WWW （World Wide Web） 统一资源定位符URL URL的定义： URL是对能从因特网上得到的资源的位置和访问方法的一种简洁的表示。 URL给资源的位置提供一种抽象的识别方法，并用这种方法给资源定位。 相当于一个文件名在网络范围的扩展； 统一资源定位符URL 格式： URL的访问方式://主机:端口/路径 使用ftp的URL /pub/abc.txt 8/pub 使用http的URL :80 RFC822格式的问题 限制 邮件信头和信体都采用7位的ASCII码传送 每个字节的最高位置零 适用条件 适于无格式的英文文本信息传输 不适于下述情况： 信体 中文或日文等非ASCII编码文本信息 包含有格式的文本信息（例如：.doc文件） 包含语音和图象等非文本信息 信头 包含非ASCII字符集信息（例如： Subject:通知） MIME：多用途Internet邮件扩展协议 ------实现对非ASCII数据的扩展 RFC 822中定义的消息头是不够的 当传输非ASCII数据时，每个消息中必须增加额外的头部 这些头部定义在RFC 2045, RFC 2046 (MIME) 邮件内容采用8位数据编码 支持中文的电子邮件收发 （中文16位编码，不会丢失最高位信息） 支持多媒体电子邮件通信 （信体可以包含多个不同格式的数据体） MIME 支持多媒体的两个关键MIME头部 Content-Type:头部 使得接收代理对消息采取正确的操作 如带JPEG图片的消息 Content-Transfer-Encoding:头部 提醒接收代理消息体已被编码，以及使用的编码类型 MIME增加的5个新的邮件首部的名称及其意义(有的可以是选项)。 （1）MIME-Version：标识MIME的版本。现在的版本号是1.0。若无此行，则为英文文本。 （2）Content-Description：这是可读字符串，说明此邮件是什么。 （3）Content-Id：邮件的惟一标识符。 （4）Content-Transfer-Encoding：在传送时邮件的主体是如何编码的。 （5）Content-Type：说明邮件的性质。 内容传送编码 最简单的编码使用7 bit或8 bit(即7位或8位ASCII码)，而每行不能超过1000个字符。 另一种编码称为quoted-printable，这种编码方法可用于当邮件中包含了非英文的文本。 对于任意的二进制文件，可用base64编码 内容类型 MIME标准规定Content-Type说明必须含有两个标识符，即内容类型(type)和子类型(subtype)，中间用“/”分开。 在MIME Content-Type中的基本类型及其意义 内 容 类 型 子 类 型 说 明 Text plain 无格式的文本 ? richtext 有少量格式命令的文本 Image gif GIF格式的静止图像 ? jpeg JPEG格式的静止图像 Audio basic 声音 Video mpeg MPEG格式的影片 Application octet-stream 不间断的字节序列 1989年3月 欧洲粒子物理实验室CERN首先提出WWW的概念； 1990年11月 第一个W