计算机网络之应用层与传输层

一、概述

OSI分层（7层）

物理层、数据链路层、网络层、运输层、会话层、表示层、应用层

TCP/IP分层（4层）

网络接口层、网络层、运输层、应用层

五层协议（5层）

物理层、数据链路层、网络层、运输层、应用层

五层结构的概述

1.应用层：通过应用进程间的交互来完成特定网络应用
数据：报文
协议：HTTP, SMTP(邮件), FTP(文件传送)

2.运输层：向两个主机进程之间的通信提供通用的数据传输服务
数据：TCP:报文段，UDP:用户数据报
协议：TCP, UDP

3.网络层：为分组交换网上的不同主机提供通信服务
数据：数据包（Packet)或IP数据报
协议：IP

4.数据链路层：将比特组装成帧和点到点的传递
数据：帧(Frame)
协议：

5.物理层：通过媒介传输比特,确定机械及电气规范
数据：比特(Bit)
协议：

各层协议参考：各层协议

二、应用层

http协议

请求报文

常用的 HTTP 请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
GET：当客户端要从服务器中读取某个资源时，使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的部分，回送给客户端，即向服务器请求某个资源。使用GET 方法时，请求参数和对应的值附加在 URL 后面，利用一个问号(“?”)代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind
POST：当客户端给服务器提供信息较多时可以使用POST 方法，POST 方法向服务器提交数据，比如完成表单数据的提交，将数据提交给服务器处理。GET 一般用于获取/查询资源信息，POST 会附带用户数据，一般用于更新资源信息。POST 方法将请求参数封装在HTTP 请求数据中，以名称/值的形式出现，可以传输大量数据
请求头部：请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

User-Agent：产生请求的浏览器类型;
Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ / ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;
Accept-Language：客户端可接受的自然语言;
Accept-Encoding：客户端可接受的编码压缩格式;
Accept-Charset：可接受的应答的字符集;
Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机;
connection：连接方式(close 或 keepalive);
Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;

响应报文

状态码

状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：

1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;
2xx：表示服务器已成功接收到请求并进行处理;
3xx：表示服务器要求客户端重定向;
4xx：表示客户端的请求有非法内容;
5xx：表示服务器未能正常处理客户端的请求而出现意外错误;

200 OK：表示客户端请求成功;

300 Multiple Choices：多重选择，链接列表，用户可以选择某链接到达目的地。

301 Moved Permanently：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替；

302 Found：临时移动。与301类似，但资源只是临时被移动，客户端应继续使用原有URI；

303 See Other：查看其它地址。与301类似。使用GET和POST请求查看；

304 Not Modified：未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源；

400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解;

401 Unauthonzed：表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用;

403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因;

404 Not Found：请求的资源不存在，例如，输入了错误的URL;

500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求;

503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常;

响应头

Location：Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源;
Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。
Vary：指示不可缓存的请求头列表;
Connection：连接方式;

1.对于请求来说：close(告诉WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求);
2.对于响应来说：close(连接已经关闭); keepalive(连接保持着，在等待本次连接的后续请求); Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间(秒);例如：Keep-Alive：300;

域名系统DNS

例：某用户通过主机A浏览中山大学的主页 www.sysu.edu.cn

A向本地域名服务器DNS查询
如果DNS上有www.sysu.edu.cn的记录，就立即返回IP地址给主机A
如果DNS上没有该域名记录，则DNS向根域名服务器发出查询请求
根域名服务器把负责cn域的顶级域名服务器B的IP地址告诉DNS
DNS向B查询获得二级域名服务器C的IP地址，最终迭代查询到 www.sysu.edu.cn的ip直接返回DNS

三、传输层

使用UDP和TCP协议的各种应用和应用层协议

应用	应用层协议	运输层协议
名字转换	DNS(域名系统)	UDP
文件传送	TFTP(简单文件传送协议)	UDP
IP地址配置	DHCP(动态主机配置协议)	UDP
路由器选择协议	RIP(路由信息协议)	UDP
网络管理	SNMP(简单网络管理协议)	UDP
远程服务器	NFS(网络文件系统)	UDP
多播	IGMP(网际组管理协议)	UDP
电子邮件	SMTP(简单邮件传送协议)	TCP
远程终端	TELNET(远程终端协议)	TCP
万维网	HTTP(超文本传送协议)	TCP
文件传送	FTP(文件传送协议)	TCP

端口

TCP和UDP都需要有源端口和目的端口

端口：用16位来表示,即一个主机共有65536个端口.序号小于256的端口称为通用端口,如FTP是21端口,WWW是80端口等.端口用来标识一个服务或应用.一台主机可以同时提供多个服务和建立多个连接.端口(port)就是传输层的应用程序接口.应用层的各个进程是通过相应的端口才能与运输实体进行交互.服务器一般都是通过人们所熟知的端口号来识别的

服务端常用的熟知端口

应用程序	FTP	DNS	HTTP
熟知端口	21	53	80

登记端口 1024~49151

客户端端口号由客户进程动态选择，数值范围 49152~65535。

TCP

TCP(Transmission Control Protocol 传输控制协议)是一种可靠传输的协议。面向字节流、全双工通信、可靠、面向连接。

特点

面向连接的运输层协议
点对点（一对一）通信
可靠交付
全双工通信（TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据）
面向字节流

数据报文段解析

源端口号/目的端口号: 表示数据从哪个进程来, 到哪个进程去
32位序列号（seq）:用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号
32位确认号（ack）：只有ACK标志为1时，确认号字段才有效。ack表示期待收到对方下一个报文段的第一个数据字节的序号。序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。
4位首部长度: 表示该tcp报头有多少个4字节(32个bit)
6位保留: 顾名思义, 先保留着, 以防万一
6位标志位
URG: 标识紧急指针是否有效
ACK: 占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走
RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段
SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段
FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段
16位窗口大小:
16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分
16位紧急指针: 用来标识哪部分数据是紧急数据
选项和数据暂时忽略

连接管理机制

正常情况下, tcp需要经过三次握手建立连接, 四次挥手断开连接

三次握手

第一次:
客户端 - - > 服务器此时服务器知道了客户端要建立连接了
第二次:
客户端 < - - 服务器此时客户端知道服务器收到连接请求了
第三次:
客户端 - - > 服务器此时服务器知道客户端收到了自己的回应

到这里, 就可以认为客户端与服务器已经建立了连接.

刚开始, 客户端和服务器都处于 CLOSE 状态.
此时, 客户端向服务器主动发出连接请求, 服务器被动接受连接请求.

TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN（监听）状态
TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，自己的序列号是 x+1。
此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

为什么不用两次?

主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么不用四次?

因为三次已经可以满足需要了, 四次就多余了.

四次挥手

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么最后客户端还要等待 2*MSL的时间呢?

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接, 但是客户端突发故障了怎么办?
-TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

UDP

UDP（User Datagram Protocol），用户数据报协议，是OSI(Open System Interconnection，开放式系统互联) 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP提供了无连接通信，且不对传送数据包进行可靠性保证，适合于一次传输少量数据，UDP传输的可靠性由应用层负责

UDP的包头
UDP的包头格式很简单，只有源端口号和目标端口号：

UDP的三大特点

沟通简单，秉承性善论，相信网络通路默认就是很容易送达的，不容易被丢弃的；
轻信他人，不会建立连接，虽然有端口号，但是监听在这个地方，谁都可以传给他数据，也可以传给任何人数据；
愣头青，做事不懂权变，不会根据网络的情况进行发包的拥塞控制，无论网络丢包丢成啥样了，它该怎么发还怎么发；

UDP的三大使用场景

需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用；
不需要一对一沟通，建立连接，而是可以广播的应用；UDP的不面向连接的功能，可以使得可以承载广播或者多播的协议。DHCP就是一种广播的形式，就是基于UDP协议的；
需要处理速度快，时延低，可以容忍少数丢包，即便网络堵塞，也毫不退缩，一往无前的时候；UDP简单、处理速度快，不像TCP一样，操那么多心；TCP在网络不好出现丢包的时候，拥塞控制策略会主动的退缩，降低发送速度，这就相当于本来环境就差，还自断臂膀，用户本来就卡，这下更卡了

TCP与UDP的区别

TCP面向连接，UDP面向无连接
TCP 提供可靠交付，UDP继承了IP包的特性，不保证不丢失，不保证按时到达；
TCP是面向字节流的，发送的时候发的是一个流，没头没尾的。UDP继承了IP的特性，基于数据报的，一个个发，一个个收；
TCP是可以有拥堵控制的，可以根据网络环境调整自己的行为；UDP就是应用让我发，我就发，管它洪水滔天；
TCP是一个有状态的服务，通俗的讲就是有脑子的，可以精确的记着，自己发送了没有，接收到没有，发送到哪个了，应该接收到哪个了，错一点儿都不行；UDP其实是一个无状态服务，无脑子，天真无邪的发出去就发出去呗；

参考文章：

https://blog.csdn.net/vip97yigang/article/details/78306837
TCP详解