深入学习计算机网络-自顶向下方法-应用层(二)

前言:

本章主要知识有,网络应用的原理:网络应用协议的概念和实现方面,传输层的服务模型,客户-服务器模式,对等模式(peer-to-peer),内容分发网络,网络应用的实例,互联网流行的应用层协议,HTTP,FTP,SMTP / POP3 /IMAP,DNS。编程:网络应用程序Socket API。

目录:             

0X00应用层原理

0X01Web与HTTP

 0X02FTP文件传输协议

0X03EMail协议

0X04DNS域名解析协议

0X05TCP-socket编程

0X06UDP-socket编程

0X07总结

 

0X00应用层原理

网络应用  

  因为socket API 导致网络应用门槛很低,可以充分的利用发挥自己的创意,网络应用蓬勃发展,互联网创新大力发展。创建网络应用

服务器环境搞好,客户端 浏览器 让客户去下载 一个服务就跑起来了,部署系统因为在端系统,所以部署速度非常快,在网络核心中也没有设备介入,所以说网络应用部署非常便捷。

网络应用的体系架构

客户-服务器模式(C/S:client/server):

CS架构

服务器:

  • 一直运行
  • 固定的IP地址和周知的端口号(约定)
  • 扩展性:服务器场
  • 数据中心进行扩展
  • 扩展性差

客户端:

  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可能是动态IP 地址
  • 不直接与其它客户端通信

服务器一直运行 固定ip和约好的端口 web服务器就是这样 用80端口  本站就使这样。

问题:扩展性差 几百个并发可以承受,如果需求扩大到几万 几十万并发呢?

cpu没办法扩 带宽也要扩 只能换服务器。

正常的模式:随着用户的增加 直线下降 正常

CS模式:达到一个数量时呈现断崖式下降

CS模式的图像

服务器一旦宕机 ,服务全部都寄。

对等模式(P2P:Peer To Peer):

ptp

(几乎)没有一直运行的服务器,任意端系统之间可以进行通信,每一个节点既是客户端又是服务器

自扩展性-新peer节点带来新的服务能力,当然也带来新的服务请求,参与的主机间歇性连接且可以

改变IP 地址,但是难以管理。例如: Gnutella,迅雷

每一个节点即使 客户端 也是 服务器,具有自扩展性 。

问题:管理困难 提供服务能力不稳定,上线才能提供服务。

这两种模式第一章也详细了解过了 下面还有一种就是这两种的结合体。

混合体:客户-服务器和对等体系结构:

Napster:

 文件搜索:集中

  • 主机在中心服务器上注册其资源
  • 主机向中心服务器查询资源位置

 文件传输:P2P

  • 任意Peer节点之间

即时通信:

 在线检测:集中

  • 当用户上线时,向中心服务器注册其IP地址
  • 用户与中心服务器联系,以找到其在线好友的位置

 两个用户之间聊天:P2P

Napster是以前某个大学大一学生写出来的系统,就是文件共享,在学校里共享音乐资源什么,大家就可以不用买CD,后来被告了,服务器被拔了,但是这种思想很经典。

Napster 这种混合体就是 下载某个文件时 向服务器查询那个节点有该资源,然后返回此节点位置,让其下载。 一个节点有资源时 向服务器请求注册 告诉服务器 该节点有某种资源

进程通信

一个端系统内的两个进程通信:

进程通信内部

如果两个应用进程在一个端系统上进行通信,则借助操作系统就可以完成 ,管道,消息队列,共享内存等等。

在同一个主机内,使用进程间通信机制通信(操作系统定义)。

两个端系统的两个进程通信:

系统内通信

如果两个应用进程不在同一个端系统,就需要借助网络进行报文的发送。

不同主机,通过交换报文(Message)来通信,使用OS提供的通信服务,按照应用协议交换报文,借助传输层提供的服务

不同主机端系统进程通信的注意

不同主机端通信的注意

分布式进程通信需要解决的问题

需要解决的问题

问题1:进程标示和寻址问题(服务用户)

解决方式:对进程进行编址(addressing)

进程为了接收报文,必须有一个标识 即:SAP(发送也需要标示)

      主机:唯一的 32位IP地址

  • 仅仅有IP地址不能够唯一标示一个进程;在一台端系统上有很多应用进程在运行,所采用的传输层协议:TCP or UDP端口号(Port Numbers)

      一些知名端口号的例子:

  • HTTP: TCP 80 Mail: TCP25 ftp:TCP 2

一个进程:用IP+port标示 端节点

本质上,一对主机进程之间的通信由2个端节点构成

举个例子把 假如本网站服务器ip为1.1.1.1  web服务器采用TCP传输  然后开放在80端口

那么他在网络上的标识SAP就是1.1.1.1 TCP 80  你用你电脑访问本网站时候,你的浏览器就会以这个地址为目标进行访问。

问题2:传输层提供的服务-需要穿过层间的信息

这个问题乍看有点懵,解释一下,就是你寄快递,你要给快递公司什么东西? 第一 要有你寄的货物吧?

第二要有你寄去哪里的信息吧?  第三 是不是还要有你自己的信息?不然对方收到怎么知道谁寄的?

这么一说就简单多了,应用层想要传输东西,就要交给传输层这三样东西。

层间接口必须要携带的信息

  • 要传输的报文(对于本层来说:SDU) —就是货物
  • 谁传的:自己的应用进程的标示:IP+TCP(UDP) 端口  —谁寄的
  • 传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号 —寄给谁的

传输层实体(tcp或者udp实体)根据这些信息进行TCP

  • 报文段(UDP数据报)的封装
  • 源端口号,目标端口号,数据等
  • 将IP地址往下交IP实体,用于封装IP数据报:源IP,目标IP

问题2延申传输层提供的服务-层间信息的代表

加入你跟一个朋友经常寄邮件,每次都要写一大堆 对方信息 自己信息,频率低一点感觉还好,比如一个月寄一次,那么如果频率很高怎么办? 比如一天寄50次,每次都要写你受的了吗? 当然受不了,然后计算机网络的通信比这个频率还高,所以要解决它怎么办,可以这样跟快递公司约定好,我把这个固定的朋友定义为1,我每次说寄给1 那么快递公司就知道什么意思了 他就把之前那个信息拿出来继续用,这样效率就快的多了。

层间信息代表

句柄 就是指针 懂了吧,Socket 就是一个本地标识管理使用的。

个人理解就是结构体,结构体里有这个信息,然后句柄就是这个结构体的指针。

通过管理句柄 就是对该结构体进行操作,达到穿过的信息量最小,操控的信息量最大。

TCP之上的套接字(socket)

对于使用面向连接服务(TCP)的应用而言,套接字是4元组的一个具有本地意义的标示

  • 4元组:(源IP,源port,目标IP,目标port)
  • 唯一的指定了一个会话(2个进程之间的会话关系)
  • 应用使用这个标示,与远程的应用进程通信
  • 不必在每一个报文的发送都要指定这4元组
  • 就像使用操作系统打开一个文件,OS返回一个文件句柄一样,以后使用这个文件句柄,而不是使用这个文件的目录名、文件名
  • 简单,便于管理

TCP socket

第一次往目标主机发送报文的时候 创建一个4元组。

TCPsocket维持

22222 socket在ip2.2.2.2代表 80 和233的会话关系,以此类推。

问题2:传输层提供的服务-层间信息代码

上面那个是TCP,这个是UDP,原理相同,都是为了省事,效率高。

UDPsocket

UDP之上的套接字(socket)

对于使用无连接服务(UDP)的应用而言,套接字是2元组的一个具有本地意义的标示

  • 2元组:IP,port (源端指定)
  • UDP套接字指定了应用所在的一个端节点(end point)
  • 在发送数据报时,采用创建好的本地套接字(标示ID),就不必在发送每个报文中指明自己所采用的ip和port
  • 但是在发送报文时,必须要指定对方的ip和udpport(另外一个段节点)

因为UDP 不用对方知道自己是谁,只管寄出去,丢了算了,我寄出去就行了。

TCP 相当于寄邮件经常相互寄是四元组,双方信息都要知道。

UDP相当于 你经常给别人寄 别人不跟你寄 所以是二元组。

UDPsocket例子

套接字(Socket)

进程向套接字发送报文或从套接字接收报文

套接字 <-> 门户

  • 发送进程将报文推出门户,发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
  • 接收进程从另外一端的门户收到报文(依赖于传输层设施)

socket

问题3如何使用传输层提供的服务实现应用

要做好以下三件事:

  • 定义应用层协议:报文格式,解释,时序等
  • 编制程序,通过API调用网络基础设施提供通信
  • 服务传报文,解析报文,实现应用时序等

目前在第五层 就是以第五层的视角来看别的东西 ,socket就是传输层提供服务的一个方式。                                       socket任意门

现在以应用层角度来看 就是把东西交给socket这个门 然后另一个ip上的应用就通过这个门收到了

有点像任意门 传送门,哆啦A梦直呼内行!

应用层协议 

应用层协议定义了:运行在不同端系统上的应用进程如何相互交换报文

  • 交换的报文类型:请求和应答报文
  • 各种报文类型的语法:报文中的各个字段及其描述
  • 字段的语义:即字段取值的含义
  • 进程何时、如何发送报文及对报文进行响应的规则

应用协议仅仅是应用的一个组成部分

  • Web应用:HTTP协议,web客户端,web服务器,HTML

公开协议:

  • 由RFC文档定义
  • 允许互操作
  • 如HTTP, SMTP

专用(私有)协议:

  • 协议不公开
  • 如:Skype

应用需要传输层提供什么样的服务?

数据丢失率

  • 有些应用则要求100%的可靠数据传输(如文件)
  • 有些应用(如音频)能容忍一定比例以下的数据丢失

吞吐

  • 一些应用(如多媒体)必须需要最小限度的吞吐,从而使得应用能够有效运转
  • 一些应用能充分利用可供使用的吞吐(弹性应用)

延迟

  • 一些应用 出于有效性考虑,对数据传输有严格的时间限制
  • Internet 电话、交互式游戏延迟、延迟差

安全性

  • 机密性
  • 完整性
  • 可认证性(鉴别)

常见应用对传输服务的要求

根据常识就可以判断,比如你下载某个东西时候 肯定不能缺少一个数据,至于延迟要求就不严重,大不了就是下载慢一点,再比如打视频,如果丢了一个数据也没事,我们可以根据前后数据理解语义,但是对延迟就要求高了。

应用服务要求

Internet 传输层提供的服务

   TCP 服务:

  • 可靠的传输服务
  • 流量控制:发送方不会淹没接受方
  • 拥塞控制:当网络出现拥塞时,能抑制发送方
  • 不能提供的服务:时间保证、最小吞吐保证和安全
  • 面向连接:要求在客户端进程和服务器进程之间建立连接

 UDP 服务:

  • 不可靠数据传输
  • 不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立连接

为什么要有 UDP?

能够区分不同的进程,而IP服务不能

  • 在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程

无需建立连接,省去了建立连接时间,适合事务性的应用

不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用

  • 因为为了实现可靠性(准确性、保序等),必须付出时间代价(检错重发)

没有拥塞控制和流量控制,应用能够按照设定的速度发送数据

  • 而在TCP上面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一致的,因为有流量控制和拥塞控制

有些应用有可靠机制反而不好。

有些 出错报文采用TCP来传太耽误时间了 反而UDP直接丢掉更省事。

摆烂先驱 UDP,我只管发,别的啥也不管。

Internet应用及其应用层协议和传输协议

应用层协议

TCP/UDP 不提供安全 明文传输 电子邮件也是明文

安全TCP

安全TCP

SSL位置

SSl是在应用层!应用层加密后在给传输层!

0X01Web与HTTP

一些术语

Web页:由一些对象组成

  • 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
  • Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
  • 通过URL对每个对象进行引用
  • 访问协议,用户名,口令字,端口等;

URL格式:

URL

任何协议都可以采用URL的方式访问,这是个新奇的,以前接触的只有http https,端口应该在主机名后面

现在的网站都支持匿名访问,所以访问的时候不用输入用户名,口令。不输入端口是因为默认端口。

访问一个网站时候 先拿到basic html 然后对应区域的内容 图片等 通过链接画出来。

web就是之前说的杀手级应用。

HTTP概况

Http

HTTP: 超文本传输协议

Web的应用层协议:

    客户/服务器模式

  • 客户: 请求、接收和显示Web对象的浏览器
  • 服务器: 对请求进行响应,发送对象的Web服务器

超文本:不是线性文本,指的是文本之间任意的指向关系。

网页通过超文本构成了一个巨大复杂的网络信息空间。

web主流的服务器有:apache nginx 微软的iis

HTTP对应的RFC文档:

  • HTTP 1.0: RFC 1945
  • HTTP 1.1: RFC 2068

不管是移动端还是PC 上网时都遵循http,先发送请求报文,等响应报文。

使用TCP过程:

  • 客户发起一个与服务器的TCP连接 (建立套接字) ,端口号为 80
  • 服务器接受客户的TCP连接
  • 在浏览器(HTTP客户端)与 Web服务器(HTTP服务器 server)交换HTTP报文 (应用层协议报文)
  • TCP连接关闭

服务器有一个原始的socket (守候socket)等待客户机 来建立请求,一旦建立成功,就用另一个socket(维持socket)来维持这个请求。

HTTP是无状态的:服务器并不维护关于客户的任何信息!

也就是说你请求我,我就回应你,然后就断开连接,别的我不管,那么一些认证谁来管呢?等会下面出现个cookies,他来管。

为什么服务器不维护客户的信息?

维护状态的协议很复杂!

  • 必须维护历史信息(状态)
  • 如果服务器/客户端死机,它们的状态信息可能不一致,二者的信息必须是一致
  • 无状态的服务器能够支持更多的客户端

说白了就是代价太大了,不划算,访问一个网页,网页画出来后 链接就关掉了,服务器不维护客户端状态,无状态不维护历史信息,历史信息就是你以前访问过我不什么的信息我不管。

HTTP连接

非持久HTTP

  • 最多只有一个对象在TCP连接上发送
  • 下载多个对象需要多个TCP连接
  • HTTP/1.0使用非持久连接

http 1.0版本示意图 非持久连接

http1.0

http1.0连接过程:

TCP连接请求

TCP连接确认

http请求

http响应

TCP连接拆除请求

TCP连接拆除确认

持久HTTP

  • 多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输
  • HTTP/1.1 默认使用持久连接

http1.1

这个啥意思呢 就是说上面非持久连接不是传一个对象就关闭连接,再传对象就要重新建立连接,浪费时间,因为还要再请求再响应一次,而这个持久连接就是传完一个对象,连接不会关,而是能够继续传输对象,节省了时间。

http1.0非持久连接过程分析:

假设Http连接

假设Http连接2

他每次引用一个对象都要重复1-5。

响应时间模型:

响应时间模型

往返时间RTT(round-triptime):

一个小的分组从客户端到服务器,在回到客户端的时间(传输时间忽略)响应时间:

  • 一个RTT用来发起TCP连接
  • 一个 RTT用来HTTP请求并等待HTTP响应

文件传输时间

共:2RTT+传输时间

持久HTTP

非持久HTTP的缺点:

  • 每个对象要2个 RTT
  • 操作系统必须为每个TCP连接分配资源
  • 但浏览器通常打开并行TCP连接,以获取引用对象

持久HTTP

  • 服务器在发送响应后,仍保持TCP连接
  • 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
  • 客户端在遇到一个引用对象的时候,就可以尽快发送该对象的请求

非流水方式的持久HTTP:

  • 客户端只能在收到前一个响应后才能发出新的请求
  • 每个引用对象花费一个RTT

流水方式的持久HTTP:

  • HTTP/1.1的默认模式
  • 客户端遇到一个引用对象就立即产生一个请求
  • 所有引用(小)对象只花费一个RTT是可能的,因为同时发出请求,可能一个请求的时间就都把对象给响应回来了。

HTTP请求报文

两种类型的HTTP报文:请求、响应

HTTP请求报文:

  • 采用ASCII码 ,这样的报文人能阅读

请求报文

Get 请求HTML网页的头部和 body 都要,POST上载

HEAD 这个请求很特殊,只要头 不是常规用户用的 搜索引擎用的 建立索引用的

user-agent 用户浏览器版本。、

Connection : close 请求对象回来 连接就关掉 虽然是http1.1 但是也可以让他关掉。

get和post是HTTP与服务器交互的方式
说到方式,其实总共有四种:put,delete,post,get,他们的作用分别是对服务器资源的增,删,改,查。
所以,get是获取数据,post是修改数据。

区别:get把请求的数据放在url上,即HTTP协议头上,其格式为:以?分割URL和传输数据,参数之间以&相连,数据如果是英文字母/数字,原样发送,如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,及“%”加上“字符串的16进制ASCII码”。

例如:Get 方法通过 URL 请求来传递用户的数据,将表单内各字段名称与其内容,以成对的字符串连接,置于URL 后,如http://www.xxx.com/index.php?username=liming&password=123456 数据都会直接显示在 URL 上,就像用户点击一个链接一样。Post 方法通过 HTTP Post 机制,将表单内各字段名称与其内容放置在 HTML 表头(header)内一起传送给服务器端。

HTTP请求报文-通用格式:

通用格式

提交表单输入

Post方式:

网页通常包括表单输入

包含在实体主体(entity body )中的输入被提交到服务器

例如:www.somesite.com/animalsearch?monkeys&banana

URL方式:方法:GET

输入通过请求行的URL字段上载

例如:http://www.baidu.com/s?wd=xx+yy+zzz&cl=3

参数:wd,cl

参数值:XX+YY+zzz,3

方法类型:

HTTP/1.0

  • GET
  • POST
  • HEAD要求服务器在响应报文中不包含请求对象,就是只要head,不要body

HTTP/1.1

  • GET, POST, HEAD
  • PUT-将实体主体中的文件上载到URL字段规定的路径
  • DELETE-删除URL字段规定的文件

HTTP响应报文

响应报文

200-ok表示请求的内容存在  404-找不到该内容

Last Modified 请求这个文件上次修改的日期,到后面可以相当于版本号

Content-Length 内容长度 这个非常重要 告诉传输层 往上面应用层多少字节,应用层要自己区分哪里是头 哪里是结束 ,传输层不管,应用层上的应用自己维护报文的边界和界限。

Content-Type 表示你请求内容的文件类型

HTTP响应状态码

状态码

护网过程中碰到过403,攻击别人时候被403了,403-错误是网站访问过程中,常见的错误提示, 资源不可用,服务器 理解客户的请求,但拒绝处理它。

505 版本号不支持 ,服务器不支持的你请求的http的版本

Cookies!

上面说了服务器不维护客户端状态,你发来请求 我就给你回应 那么!那么! 身份认证谁来维持?

cookies

有些网站首次访问后,服务器会给你分配一个cookie,这个cookie会保存在客户端的目录下,也会在服务器里保存,下次访问时 客户端就会带着cookie访问,服务器来对照,然后就知道你的状态 购物车什么的。

第一次访问没有cookie值 服务器生产cookie 响应中告诉客户端,后续再次访问时候 服务器的respose就不带cookie值了。

Cookies: 维护状态

cookies维护状态

cookies:用处隐私

cookies2

Web缓存 (代理服务器)

代理服务器

缓存服务器即使客户端也是服务器,降低了origin 服务器的压力 有点像cdn?

用空间换时间 有点意思。

Web缓存

缓存既是客户端又是服务器

通常缓存是由ISP安装 (大学、公司、居民区ISP)

为什么要使用Web缓存?

降低客户端的请求响应时间

可以大大减少一个机构内部网络与Internent接入链路上的流量

互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容

我理解的:到处都有2 8分布,也就是说大部分人会访问热点,比如热搜,我设置一个很小的缓存就能命中很多的访问请求,大大减轻了原始服务器的压力。

缓存示例

缓存示例

假设:

  • 平均对象大小 = 100kb
  • 机构内浏览器对原始服务器的平均请求率为 = 15请求/s
  • 平均到浏览器的速率:1.5Mbps
  • 机构内部路由器到原始服务器再返回到路由器的的延时 (Internet 延时)= 2s
  • 接入链路带宽:1.54Mbps

结果:

可以看到延时主要由三部分组成 1.客户端访问上游ISP 因为这个带宽是1G 所以这个是毫秒级ms

                                                     2.访问请求在两个ISP之间的延时由于: 

流量强度=1

            流量强度接近1了,延时很大很大,分钟级别了,你都可以去倒杯水喝完他还没加载好

       3.机构内部路由器到原始服务器再返回到路由器的的延时 (Internet 延时)= 2s

总延时 = LAN延时 + 接入延时 +Internet 延时= ms + 分 + 2s

这非常显然是让人接受不了的 请求一个网页等tm几分钟,电脑都想砸了。

解决方案:

1.土豪方案把两个ISP的带宽由1.54m —> 154M 升级一百倍

这肯定是ISP出的馊主意,运营商高兴 用户高兴 厂商不高兴了,因为相当于厂商付给ISP的费用每个月涨了100倍。

结果:

Internet 延时= ms + 分 + 2s –>Internet 延时= ms + msecs + 2s

还要2s多  也不流畅。

2.穷人方案采用web缓存服务器代理。

计算链路利用率,有缓存的延迟:假设缓存命中率0.4

40%请求在缓存中被满足,其他60%的请求需要被原始服务器满足接入链路利用率:60%的请求采用接入链路

进过接入链路到达浏览器的数据速率 = 0.6*1.50 Mbps = .9 Mbps

利用率= 0.9/1.54 = 0.58

总体延迟:= 0.6 * (从原始服务器获取对象的延迟) +0.4 * (从缓存获取对象的延迟)= 0.6 (2.01) + 0.4 (~msecs)

= ~ 1.2 secs

比安装154Mbps链路还来得小 (而且比较便宜!)

风险问题:本地的内容可能不是最新的

解决方案: http 中由 condition get 条件获取 请求报文时候加上一个头部,如果某个对象在那个时候后得到修改,就重新传给我,如果没有修改就不用传

举个例子:代理服务器第一次从origin服务器拿到一个文件的时间是 12:00,过一个小时,代理服务器去请求一下原始服务器,如果这个文件的修改时间超过了12:00 就再传一个给我 ,我进行更新,如果没有,说明这个文件传给我之后就没有修改过,就不用再传给我了

条件GET

0X02FTP文件传输协议

0X02FTP文件传输协议

FTP协议示意图

向远程主机上传输文件或从远程主机接收文件

客户/服务器模式

  • 客户端:发起传输的一方
  • 服务器:远程主机

ftp: RFC 959

ftp服务器:端口号为21

现在是 迅雷 百度云盘 群内文件分发,早期都是FTP,现在FTP没有以前用的多

先认证 通过FTP用户接口 然后通过FTP客户端发出一些指令 去完成命令

可以upload download list 对应命令是上传 下载 列出文件目录

FTP: 控制连接与数据连接分开

FTP控制连接传输连接

  • FTP客户端与FTP服务器通过端口21联系,并使用TCP为传输协议
  • 客户端通过控制连接获得身份确认
  • 客户端通过控制连接发送命令浏览远程目录
  • 收到一个文件传输命令时,服务器打开一个到客户端的数据连接
  • 一个文件传输完成后,服务器关闭连接
  • 服务器打开第二个TCP数据连接用来传输另一个文件
  • 控制连接: 带外( “out of band”)传送
  • FTP服务器维护用户的状态信息:当前路径、用户帐户与控制连接对应
  • 连接是有状态的

自我理解:

FTP 用户名口令都是明文传输,不安全 hack!

服务器主动和客户端20号端口 建立数据连接,在这个数据连接上传输文件  21号那个连接 是客户端主动连接服务器的 他是控制连接   说白了 命令你用21号端口  干活用20号端口

HTTP与FTP的区别:

http控制和传输都在一个线路上传输,http是无状态连接  FTP是有状态连接。

FTP命令、响应

FTP命令报文

给你返回331就说明用户名是对的,需要密码,返回125就是连接已经建立,425就是不能打开数据传输连接,452就是读写文件有错误。

客户端给服务器发东西叫上载

服务器给客户点发东西叫下载

0X03Email协议

电子邮件(EMail)

Email

3个主要组成部分:

  • 用户代理
  • 邮件服务器
  • 简单邮件传输协议:SMTP

用户代理

  • 又名 “邮件阅读器”
  • 撰写、编辑和阅读邮件
  • 如Outlook、Foxmail
  • 输出和输入邮件保存在服务器上

用自己话说就是 你发邮件 用你电脑上的客户端通过SMTP协议发到相应的邮件服务器,然后对方用对方的客户端通过HTTP IMAP POP3协议获得这些邮件,没啥难理解的。

用户代理:撰写发送 接受的客户端软件

Web应用的用户代理:浏览器

FTP应用用户代理:FTP客户端软件

EMail: 邮件服务器

邮件服务器

邮箱中管理和维护发送给用户的邮件

输出报文队列保持待发送邮件报文

邮件服务器之间的SMTP协议

:发送email报文

  • 客户:发送方邮件服务器
  • 服务器:接收端邮件服务器

看上面那个图很容易理解。

用户代理 设置好邮件服务器的 ip和端口 ,然后 用户代理发送邮件在队列中 , 然后邮件服务器 依照队列依次取出,然后发送到相应的目标邮件服务器,目标服务器再把对应的邮件放在对应用户的目录下。

目标用户收邮件时候 运行 用户代理 在邮件服务器中 采用 pop3 IMAP 把别人发给他的邮件拉回来 呈现在客户端里

EMail: SMTP [RFC 2821]

使用TCP在客户端和服务器之间传送报文,端口号为25

直接传输:从发送方服务器到接收方服务器

传输的3个阶段

  • 握手
  • 传输报文
  • 关闭

命令/响应交互

  • 命令:ASCII文本
  • 响应:状态码和状态信息

报文必须为7位ASCII码, 传输的字节必须在ascll码范围内 否则不允许传输

因为方便人阅读,这个方法你发英文邮件一点问题都没有,但是中文怎么办?看下面

举例:Alice给Bob发送报文

Mail举例子

  • 1) Alice使用用户代理撰写邮件并发送给bob@someschool.edu
  • 2) Alice的用户代理将邮件发送到她的邮件服务器;邮件放在报文队列中
  • 3) SMTP的客户端打开到Bob邮件服务器的TCP连接
  • 4) SMTP客户端通过TCP连接发送Alice的邮件
  • 5) Bob的邮件服务器将邮件放到Bob的邮箱
  • 6) Bob调用他的用户代理阅读邮件

有一个点需要注意 就是这个队列 你往邮件服务器传东西是要排队的,平滑一下,万一传的多了,把服务器整崩了就寄了。

还有一个就是 邮件服务器并不是收到一个邮件就立马发出去,如果收到一个立马就发出去,那它是不是要每时每刻处于一个待命的状态来检测有没有邮件发过来,这个非常耗能,所以他是一个定时发送邮件,比如每一个小时发一次等等。

简单的SMTP交互

SMTP交互

S服务器 C是客户端

SMTP协议状态码

配合这个看应该很好理解 不解释了。

安全问题:伪造一个用户发邮件 很容易 因为这都是客户端自己写的 邮件字符都是ascll字符

传中文就不行了 解决方案:补丁

如果还有其他邮件 那就接着发 不是断开 再连接 再发。

SMTP总结

SMTP总结

跟http 不同: smtp 是持久连接,发完再关

http 是拉内容的 。

http 响应报文 就一个对象 每次请求 一个一个去请

SMTP 就是多个对象,一次发完好吧

邮件报文格式

邮件报文格式

报文格式

如果报文中存在中文字符 ,不在ascll字符范围以内 就要进行扩展 MIME

用base64编码 定一个映射关系可以解决中文编码问题。

邮件访问协议

邮件访问协议

IMAP 比POP 更复杂 应为 他可以远程维护邮箱 把邮箱里面的东西搬来搬去。

HTTP 可以用于 文件的上载下载 也可以收发邮件

POP3协议

POP3

POP3 也是明文传输 安全隐患大 后来打补丁 提升安全性

两种模式 下载后删除—邮箱不会满, 下载并保留—多途径保留 从其他端系统 仍然可以看到这个邮件

pop3-2

0X04DNS域名解析协议

DNS(Domain Name System)

DNS的必要性:

  • IP地址标识主机、路由器
  • 但IP地址不好记忆,不便人类使用(没有意义)
  • 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
  • 例如:qzheng@ustc.edu.cn 所在的邮件服务器,www.ustc.edu.cn 所在的web服务器
  • 存在着“字符串”—IP地址的转换的必要性
  • 人类用户提供要访问机器的“字符串”名称
  • 由DNS负责转换成为二进制的网络地址

说白了 就是让你访问百度 你是乐意访问www.baidu.com  还是访问他的ip地址?

难道每访问一个网页都要记住他ip地址吗,那也太痛苦了,所以就有这个东西了

你输入访问域名,他帮你转换成对应的ip地址,就方便多了。

DNS是一个给其他应用 用的应用,人用不到,域名到ip地址的转换 web应用会用 ,web会调用DNS 的解析器,FTP 也会用 DNS DNS 不是给人用的

本章前面所有应用都是CS模式

本层协议的实现要靠下层的服务

DNS系统需要解决的问题以及解决方案

问题1:如何命名设备

  • 用有意义的字符串:好记,便于人类用使用
  • 解决一个平面命名的重名问题:层次化命名

DNS问题1

名字结构

DNS名字

域名(Domain Name):

  • 从本域往上,直到树根
  • 中间使用“.”间隔不同的级别
  • 例如:ustc.edu.cn,auto.ustc.edu.cn,www.auto. ustc.edu.cn
  • 域的域名:可以用于表示一个域
  • 主机的域名:一个域上的一个主机

这个什么意思呢 一个平面意思就是xiaoming,xiaogong这种,两个层面就是 China.xiaohong,多个层面就类似于我们现在的域名 someschool.edu.cn 某个大学官网

cn就是中国 edu就是教育 somechool 是学校名字,就是某个中国大学的官网。

.cn是中国的域名 .edu.cn就是中国教育网的域名 .gov.cn就是中国政府网站的域名

整体就是树状结构

域名的管理

  • 一个域管理其下的子域.jp 被划分为 ac.jp co.jp
  • .cn 被划分为 edu.cn com.cn
  • 创建一个新的域,必须征得它所属域的同意

域与物理网络无关

  域遵从组织界限,而不是物理网络

  • 一个域的主机可以不在一个网络
  • 一个网络的主机不一定在一个域

域的划分是逻辑的,而不是物理的

问题2:如何完成名字到IP地址的转换

分布式的数据库维护和响应名字查询,

如果不是分布式数据库维护 只有一个名字服务器

一个名字服务器的问题

  • 可靠性问题:单点故障
  • 扩展性问题:通信容量
  • 维护问题:远距离的集中式数据库

区域(zone)

  • 区域的划分有区域管理者自己决定
  • 将DNS名字空间划分为互不相交的区域,每个区域都是树的一部分

名字服务器:

  • 每个区域都有一个名字服务器:维护着它所管辖区域的权威信息(authoritative record)
  • 名字服务器允许被放置在区域之外,以保障可靠性

结构示意图

DNS管理结构

用一台设备DNS负责解析 也就几百个节点 也不是 问题

但是 随着 节点越来越多 重名增多 解析代价越来越大

时时刻刻 都要增加名字 节点 服务器 时刻要增删改查 始终存在维护的状态

TLD服务器

顶级域(TLD)服务器负责顶级域名(如com, org, net,edu和gov)和所有国家级的顶级域名(如cn, uk, fr, ca,jp)

  • Network solutions 公司维护com TLD服务器
  • Educause公司维护edu TLD服务器

区域名字服务器维护资源记录

资源记录(resource records)

  • 作用:维护 域名-IP地址(其它)的映射关系
  • 位置:Name Server的分布式数据库中

RR格式: (domain_name, ttl, type,class,Value)

  • Domain_name: 域名
  • Ttl: time to live : 生存时间(权威,缓冲记录)
  • Class 类别 :对于Internet,值为IN
  • Value 值:可以是数字,域名或ASCII串
  • Type 类别:资源记录的类型—见下页

DNS记录

DNS记录

资源记录的一个例子

DNS资源记录一个例子

这个配合上面的看应该不难理解吧,每行从左到右依次是 域名, ttl生存时间(下面说),网络类型 IN就是Internet,type(类型有),最右边就是type对应的value存储的信息。

DNS大致工作过程

  • 应用调用 解析器(resolver)
  • 解析器作为客户 向Name Server发出查询报文(封装在UDP段中)
  • Name Server返回响应报文(name/ip)

DNS工作流程

这个Local Name Server 就是DNS。

怎么知道Local Name server 也就是自己电脑上DNS上Ip的? 这个要么自己配,在计算机网络中

要么DHCP给你分ip时候直接给你配好了。

本地名字服务器(Local Name Server)

并不严格属于层次结构

每个ISP (居民区的ISP、公司、大学)都有一个本地DNS服务器

  • 也称为“默认名字服务器”

当一个主机发起一个DNS查询时,查询被送到其本地DNS服务器

  • 起着代理的作用,将查询转发到层次结构中

名字解析过程

目标名字在Local Name Server中

  • 情况1:查询的名字在该区域内部
  • 情况2:缓存(cashing)

有缓存就直接返回了 如果没有缓存 就查询

DNS本地流程

当与本地名字服务器不能解析名字时,联系根名字服务器顺着根-TLD 一直找到 权威名字服务器

递归查询

  • 名字解析负担都放在当前联络的名字服务器上
  • 问题:根服务器的负担太重
  • 解决: 迭代查询(iteratedqueries)

DNS递归查询

一个例子就明白了 如果美国 国内 一台电脑 访问 www. ustc .edu .cn域名

本地DNS服务器没有缓存 那么就先问 cn 服务器 然后 问edu 然后问 ustc就找到了 这个网站ip

递归就是我不知道问你 你不知道了问他 他不知道问她

每次查询都要问根服务器,根服务器表示 受不了!

迭代查询

  • 主机cis.poly.edu 想知道主机 gaia.cs.umass.edu的IP地址
  • 根(及各级域名)服务器返回的不是查询结果,而是下一个DNS的地址
  • 最后由权威名字服务器给出解析结果
  • 当前联络的服务器给出可以联系的服务器的名字
  •  “我不知道这个名字,但可以向这个服务器请求”

DNS迭代查询

这个就是不帮你问 给你线索 你自己问去 踢皮球,你碰到一个不知道的域名 只会访问根服务器一次,他给你指路,然后就没他事了。

DNS协议、报文

DNS协议:查询和响应报文的报文格式相同

有ID 可以同时 维护 并行查询 流水线的方式

DNS协议、报文

DNS报文

提高性能:采用缓存,跟前面的web缓存异曲同工

  • 一旦名字服务器学到了一个映射,就将该映射缓存起来
  • 根服务器通常都在本地服务器中缓存着,使得根服务器不用经常被访问
  • 目的:提高效率
  • 可能存在的问题:如果情况变化,缓存结果和权威资源记录不一致
  • 解决方案:TTL(默认2天)

提高了效率,也减轻了根服务器的压力。一旦一个服务器 查到这个东西 他自己就会缓存两天 

缓存是为了效率,两天后删除是为了一致性,相当于更新一次。

问题3:维护问题:新增一个域

DNS维护问题

我理解是 加一个A记录保证别人能访问到,加一个邮件服务,保证别人能联系到你。

攻击DNS 有意思的来了

DDoS 攻击

对根服务器进行流量轰炸攻击:发送大量ping

  • 没有成功
  • 原因1:根目录服务器配置了流量过滤器,防火墙
  • 原因2:Local DNS 服务器缓存了TLD服务器的IP地址,因此无需查询根服务器

向TLD服务器流量轰炸攻击:发送大量查询

  • 可能更危险
  • 效果一般,大部分DNS缓存了TLD

重定向攻击

中间人攻击

  • 截获查询,伪造回答,从而攻击某个(DNS回答指定的IP)站点

DNS中毒

  • 发送伪造的应答给DNS服务器,希望它能够缓存这个虚假的结果

技术上较困难:分布式截获和伪造利用DNS基础设施进行DDoS

  • 伪造某个IP进行查询, 攻击这个目标IP
  • 查询放大,响应报文比查询报文大
  • 影响效果有限

但是DNS的防护还是很好的,总体来说是很健壮的。

0X05TCP-socket编程

在学本节时候有一点小懵,于是加班了 出了一个番外篇幅-socket编程以及例子,用的python,这里老师讲的用的c语言,需要有数据结构和指针等C语言基础,如果不懂,结合我写的番外再看,更容易理解。

Socket编程

应用进程使用传输层提供的服务才能够交换报文,实现应用协议,实现应用

TCP/IP:应用进程使用Socket API访问传输服务

地点:界面上的SAP(Socket) 方式:Socket API

目标: 学习如何构建能借助sockets进行通信的C/S应用程序

socket: 分布式应用进程之间的门,传输层协议提供的端到端服务接口
Socket-1

2种传输层服务的socket类型:

  • TCP: 可靠的、字节流的服务
  • UDP: 不可靠(数据UDP数据报)服务

应用进程调用socket API的形式去建立socket 进行收发 然后再关掉

TCP套接字编程

套接字:应用进程与端到端传输协议(TCP或UDP)之间的门户

TCP服务:从一个进程向另一个进程可靠地传输字节流

TCP套接字编程

socket-2TCPsocket编程

socket-3

数据结构 sockaddr_in和hostent

sockaddr_in:

socket-4

hostent:

socket-5

*h_name 主机名 **h_aliases 一个指向数组的指针 是主机别名的集合

C/S socket 交互: TCP

socket-6

这里老师给了个C语言的例子,但是并不好理解 还是看番外我写的那个python更好理解

感兴趣C语言的可以网上down个源码研究研究。

0X06UDP-sockt编程

UDPsocket1

这个跟TCP不一样的就是他是一次性的,就是用的时候直接发,而不是先建立连接然后发,我随时想给你发的时候就发,TCP是打电话,那么UDP就是写信。

0X07总结

应用程序体系结构

  • 客户-服务器
  • P2P
  • 混合

应用程序需要的服务品质描述:

  • 可靠性、带宽、延时、安全

Internet传输层服务模式

  • 可靠的、面向连接的服务:TCP
  • 不可靠的数据报:UDP

流行的应用层协议:

  • HTTP
  • FTP
  • SMTP, POP, IMAP
  • DNS
  • Socket编程

更重要的:学习协议的知识

应用层协议报文类型:请求/响应报文:

  • 客户端请求信息或服务
  • 服务器以数据、状态码进行响应

报文格式:

  • 首部:关于数据信息的字段
  • 数据:被交换的信息

控制报文 vs. 数据报文

  • 带内、带外

集中式 vs. 分散式

无状态 vs. 维护状态

可靠的 vs. 不可靠的报文传输

在网络边缘处理复杂性

一个协议定义了在两个或多个通信实体之间交换报文的格式和 次序、以及就一条报文传输和接收或其他事件采取的动作

 

此文章所有内容都为本作者学习过程中整理发布,因为内容过长,可能内容中存在错误等,欢迎联系本人指正,交流学习。

 

© 版权声明
THE END
喜欢就支持一下吧
点赞9 分享
评论 抢沙发

请登录后发表评论