网络分层:
  1. 应用层
  2. 传输层
  3. 网络层
  4. 数据链路层
  5. 物理层
物理层:

比特流在节点之间的传输,是计算机连接起来的物理手段。

数据链路层:

控制网络层和物理层之间的通信,功能是在不可靠的物理线路上进行数据可靠传输。

网络层:

两台主机上应用程序端到端的通信。
两个协议:
TCP 传输控制协议,可靠。
UDP 用户数据报协议,不可靠,无连接的协议。

传输层:

Http、FTP、Telnet、SMTP、POP3

TCP的三次握手与四次挥手

三次握手流程:

  • 第一次握手:建立连接。客户端发送连接请求报文段,将 SYN 设置为 1、Sequence Number(seq)为 x;接下来客户端进入SYN_SENT状态,等待服务端的确认。

  • 第二次握手:服务器收到客户端的 SYN 报文段,对 SYN 报文段进行确认,设置Acknowledgment Number(ACK)为 x+1(seq+1);同时自己还要发送 SYN 请求信息,将SYN设置为1、seq为y。服务端将 上述所有信息放到SYN+ACK报文段中,一并发送给客户端,此时服务端进入SYN_RCVD状态。

  • 第三次握手:客户端收到服务端的SYN+ACK报文段;然后将ACK设置为y+1,向服务端发送ACK报 文段,这个报文段发送完毕后,客户端和服务端都进入ESTABLISHED (TCP连接成功)状态,完成TCP的 三次握手。
    ![](file:///D:/Users/Documents/My%20Knowledge/temp/5b627258-36ae-458c-89f0-d3e23665402f/128/index_files/e752ee91-6e21-4ac9-957d-d5a0495aa4d4.png)

四次挥手过程:

  • 第一次挥手:客户端设置seq和ACK,向服务端发送一个FIN报文段。此时,客户端进入FIN_WAIT_1 状态,表示客户端没有数据要发送给服务端了。
  • 第二次挥手:服务端收到了客户端发送的FIN报文段,向客户端回了一个ACK报文段。
  • 第三次挥手:服务端向客户端发送 FIN 报文段,请求关闭连接,同时服务端进入LAST_ACK状态。
  • 第四次挥手:客户端收到服务端发送的FIN报文段,向服务端发送ACK报文段,然后客户端进入 TIME_WAIT状态。服务端收到客户端的ACK报文段以后,就关闭连接。此时,客户端等待2MSL(最大报 文段生存时间)后依然没有收到回复,则说明服务端已正常关闭,这样客户端也可以关闭连接了。
Http协议原理
Http协议特点:
  • 支持CS模式
  • 简单快速
  • 灵活
  • 无状态

格式:
http://host[":"port][abs_path]
http://主机域名或者IP地址[":"端口号][请求资源的URI]

Http请求报文:


请求行由请求方法、URL字段和HTTP协议的版本组成,格式如下:
Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法;Request-URI是一个统一资源标识符;HTTP-Version表示请求的HTTP协议 版本;CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。
HTTP请求方法有8种,分别是GET、POST、HEAD、PUT、DELETE、TRACE、CONNECT、 OPTIONS。对于移动开发最常用的就是GET和POST了。

  • GET:请求获取Request-URI所标识的资源。
  • POST:在Request-URI所标识的资源后附加新的数据。
  • HEAD:请求获取由Request-URI所标识的资源的响应消息报头。
  • PUT:请求服务器存储一个资源,并用Request-URI作为其标识。
  • DELETE:请求服务器删除Request-URI所标识的资源。
  • TRACE:请求服务器回送收到的请求信息,主要用于测试或诊断。
  • CONNECT:HTTP 1.1协议中预留给能够将连接改为管道方式的代理服务器。
  • OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项和需求。

请求报头

在请求行之后会有0个或者多个请求报头,每个请求报头都包含一个名字和一个值,它们之间用英文冒 号“:”分割。

请求数据

请求数据不在GET方法中使用,而在POST方法中使用。POST方法适用于需要客户填写表单的场合, 与请求数据相关的最常用的请求报头是Content-Type和Content-Length。

Http响应报文:


HTTP 的响应报文由状态行、响应报头、空行、响应正文组成。
状态行格式如下所示: HTTP-Version Status-Code Reason-Phrase CRLF 其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态码;ReasonPhrase表示状态码的文本描述。
1xx:指示信息–表示请求已接收,继续处理
2xx:成功–表示请求已被成功接收、理解、接受
3xx:重定向–要完成请求必须进行更进一步的操作
4xx:客户端错误–请求有语法错误或请求无法实现
5xx:服务器端错误–服务器未能实现合法的请求

200:请求被正常处理
204:请求被受理但没有资源可以返回
206:客户端只是请求资源的一部分,服务器只对请求的部分资源执行GET方法,相应报文中通过Content-Range指定范围的资源。
301:永久性重定向
302:临时重定向
303:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上
304:发送附带条件的请求时,条件不满足时返回,与重定向无关
307:临时重定向,与302类似,只是强制要求使用POST方法
400:请求报文语法有误,服务器无法识别
401:请求需要认证
403:请求的对应资源禁止被访问
404:服务器无法找到对应资源
500:服务器内部错误
503:服务器正忙

http消息报头:

消息报头分为通用报头、请求报头、响应报头、实体报头等。消息报头由键值对组成,每行一对,关 键字和值用英文冒号“:”分隔。
消息报头分为通用报头、请求报头、响应报头、实体报头等。消息报头由键值对组成,每行一对,关
键字和值用英文冒号“:”分隔。
1.通用报头
它既可以出现在请求报头,也可以出现在响应报头中,如下所示。
• Date:表示消息产生的日期和时间。
• Connection:允许发送指定连接的选项。例如指定连接是连续的;或者指定“close”选项,通知服务
器,在响应完成后,关闭连接。
• Cache-Control:用于指定缓存指令,缓存指令是单向的(响应中出现的缓存指令在请求中未必会出
现),且是独立的(一个消息的缓存指令不会影响另一个消息处理的缓存机制)。
2.请求报头
请求报头通知服务器关于客户端请求的信息。典型的请求报头如下所示。
• Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
• User-Agent:发送请求的浏览器类型、操作系统等信息。
• Accept:客户端可识别的内容类型列表,用于指定客户端接收哪些类型的信息。
• Accept-Encoding:客户端可识别的数据编码。
• Accept-Language:表示浏览器所支持的语言类型。
• Connection:允许客户端和服务器指定与请求/响应连接有关的选项。例如,这时为Keep-Alive则表示
保持连接。
• Transfer-Encoding:告知接收端为了保证报文的可靠传输,对报文采用了什么编码方式。
3.响应报头
用于服务器传递自身信息的响应。常见的响应报头如下所示。
• Location:用于重定向接收者到一个新的位置,常用在更换域名的时候。
• Server:包含服务器用来处理请求的系统信息,与User-Agent请求报头是相对应的。
4.实体报头
实体报头用来定义被传送资源的信息,其既可用于请求也可用于响应。请求和响应消息都可以传送一
个实体。常见的实体报头如下所示。
• Content-Type:发送给接收者的实体正文的媒体类型。
• Content-Lenght:实体正文的长度。
• Content-Language:描述资源所用的自然语言。
• Content-Encoding:实体报头被用作媒体类型的修饰符。它的值指示了已经被应用到实体正文的附加
内容的编码,因而要获得Content-Type报头域中所引用的媒体类型,必须采用相应的解码机制。
• Last-Modified:实体报头用于指示资源的最后修改日期和时间。
• Expires:实体报头给出响应过期的日期和时间。

版权声明:本文为androidsuperman原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/androidsuperman/p/9846148.html