FTP-HTTP-HTTPS的学习总结

FTP协议的学习

一，学习的要点

 ftp的掌握总体架构、了解状态机

请求响应的格式、常用操作码及响应的含义

PORT与PASV的区别、断点续传

上传、下载文件的基本流程

   1，FTP的架构主要有两种形式

 

  UserPI（用户解释器）和ServerPI（服务器解释器）建立控制连接

  UserDTP（用户数据传输过程）和ServerDTP（服务器数据传输过程）建立数据连接

  用户的指令驱动数据传输

  服务器的响应让用户端知道FTP过程的状态

 

         这是一个用户端与两个FTP服务器建立控制连接，两个服务器之间建立数据连接的架构。用户端向两个服务器发送指令，来控制两个服务器之间的数据传输。

        下面以一个例子说明用户端怎么通过指令来控制服务器A和B之间的数据传输，以A向B发送数据为例子

C->A:Connect（C与A建立控制连接）	C->B:Connect（C与B建立控制连接）
C->A:PASV（C与A进入被动连接的模式） A->C:227+（IP+端口）
	C->B:PORT（A的IP+端口） B->C：200 okay
C->A:STOR	C->B: RETR

2，FTP请求的命令

   FTP请求的命令分为三类：访问控制命令，传输参数命令，服务命令

   访问控制命令主要与账户登录和退出及改变工作目录有关的命令

   传输参数命令主要是传输IP地址和端口号，及文件传输的类型，格式参数

   服务命令主要是进行数据的上传和下载，断点上传和下载及重命名等

   具体命令见RFC文档

3，响应码

   响应码由三位数字组成，每一位的数字都代表不同的类型

   1yz:positive preliminary reply

      预备应答，常见的就是数据上传和下载命令发出后，会有一个1yz的响应，告诉对方可以进行数据传输了，传输完成后回应2yz响应

   2yz：positive completion reply

      完成回答，成功接收命令并执行了命令

   3yz：positive intermediate reply

      中间应答，这个我个人理解就是先暂时给你一个中间答复，不说命令执行成功了还是失败了，具体还要看你后面的表现。常见的就是登陆过程，当用户端发送了USER 命令后，服务器端会给一个3yz的响应，告诉用户端还需要密码验证

   4yz: transient negative completion reply

      暂时拒绝回答，当服务器端忙不过来的时候，会给一个4yz的应答，这时候服务器会预留一个时间，让用户端可以重发这个命令

   5yz：permanent negative completion reply

      永久拒绝回答，收到这个回复，意味着用户端的命令没有执行

第二位数字也有各自的意义，这里就不一一列出了

HTTP协议的学习

一，学习的要求

请求响应的格式

各个操作码及响应的含义

常用头域字段的含义

相对URL与绝对URL的区别

   1，请求的格式,方法，及请求的头域

Request = request-line

             *((general-header|

Request-header|

Entity-header) CRLF)

              CRLF

[entity-body]

     Request-line = Method sp Request-URI sp HTTP-version CRLF

Method方法主要有8个方法

      OPTIONS:请求服务器告知其支持的各项技能  

              OPTIONS * HTTP/1.1  通常服务器会回应ALLOW:GET,HEAD（只是打个比方）

      GET：从服务器获取资源

      HEAD：与GET方法类似，只不过回应的时候不带实体，只返回头域

      POST，PUT：这两个方法一起讲，因为他们都是向服务器发送数据，网上也有很多讲这两个方法的不同点，在RFC文档上，两者最根本的区别在于其请求的URI意义不一样，PUT方法是不会将数据apply到另一个资源上去，post方法可用于在存在的资源上注释，通过追加操作来扩展数据库，发送新闻等

      DELETE：删除资源

      TRACE：记录经过的代理服务器

      CONNETC：这个与代理服务器相连时使用

  2，响应的格式，响应码

     Response = status -line

              *((general-header|

response-header|

entity-header)  CRLF)

CRLF

[entity-body]

      Status-line = HTTP-VERSION SP STATUS-CODE SP REASON-PHRASE CRLF

     响应吗

     1XX:informational  请求接收了，但需要后续的

     2XX：success  请求被成功接收，理解并且执行了

     3XX：redirection 重定向

     4XX：client error

     5XX:  server error

 HTTPS协议的学习

 

由于HTTP是明文传输，在HTTP的基础上，为了保证传输数据的保密性，加强安全，发展出了HTTPS。在传输数据之前，会进行TLS协议的握手，双方约定加密的过程。针对上面的图进行解释。

1，首先客户端会发送一个clienthello给服务器端

   Clienthello包含的内容有：

确定使用的协议版本号

生成一个随机数，设为R1，用于后面密码的生成。

SessionID,若为初次握手，则该项为0

密码套件，客户端会列出所支持的加密方法

压缩方法

2，服务器端接收到客户端的clienthello后也会发送一个serverhello

  Serverhello的作用是：

确定使用的协议版本

生成一个SessionID

生成一个随机数R2

确定使用的加密方法

确定使用的压缩方法

3，服务器端向接收端发送证书certificate

4,  服务器端发送serverkeyexchange报文,该条报文的作用是携带额外的密码交换的参数。

5，serverhellodone服务器端告诉接收端，hello阶段结束

6，客户端接收服务器端的证书，验证证书的有效性

7，客户端利用相关算法生成第三个随机数为pre-master-secret，利用RSA（非对称加密）或者（DH对称加密），将该数发给服务器端

8，至此两端都拥有三个随机数，利用这三个参数生成mater-secret。

9，客户端发送changecipherspec报文告诉服务器端，接下来进入数据加密传输方式

10，客户端发送finish报文，其实这个报文是用主密钥加密，给服务器端，看服务器端能不能将这个报文解密，也是在正式传输数据之前进行一次演练

11，服务器端也利用三个随机数生成master-secret，并对客户端发送过来的finish报文进行解密，并发送changecipherspec报文告诉客户端进入加密方式

12，服务器端同样加密一段数据发给客户端，即finish报文

13，客户端解密服务器端的finish报文，上述所有步骤成功的话

14，进入数据加密传输