网络模型

OSI分层模型

OSI 模型(Open System Interconnection model)是一个由国际标准化组织􏰁提出的概念模型，试图供一个使各种不同的计算机和网络在世界范围内实现互联的标准框架。它将计算机网络体系结构划分为七层，每层都可以提供抽象良好的接口，分别是:

• 物理层物理层负责最后将信息编码成电流脉冲或其它信号用于网上传输。
• 数据链路层：数据链路层通过物理网络链路􏰁供数据传输。
• 网络层：网络层负责在源和终点之间建立连接。
• 传输层：传输层向高层提供可靠的端到端的网络数据流服务。
• 会话层：会话层建立、管理和终止表示层与实体之间的通信会话；建立一个连接（自动的手机信息、自动的网络寻址）。
• 表示层：表示层􏰁供多种功能用于应用层数据编码和转化,以确保以一个系统应用层发送的信息 可以被另一个系统应用层识别。
• 应用层：OSI 的应用层协议包括文件的传输、访问及管理协议(FTAM) ,以及文件虚拟终端协议(VIP)和公用管理系统信息(CMIP)等。

OSI通信模型.png

常见的应用层协议

TCP/IP模型

OSI 模型所分的七层，在实际应用中，往往有一些层被整合,或者功能分散到其他层去。TCP/IP 没有照搬 OSI 模型，也没有 一个公认的 TCP/IP 层级模型，这里采用通用的四层来介绍。

• 链路层：链路包括用于协作IP数据在已有网络介质上传输的协议。
  它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议，供 TCP/IP 协议的数据结构和实际物理硬件之间的接口。

• 网络层：网间层对应于 OSI 七层参考模型的网络层，本层包含 IP 协议、RIP 协议(Routing Information Protocol，路由信息协议)，负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。

• 传输层：传输层对应于 OSI 七层参考模型的传输层,它􏰁供两种端到端的通信服务。其中 TCP 协议(Transmission Control Protocol)􏰁供可靠的数据流运输服务，UDP 协议(Use Datagram Protocol)􏰁供不可靠的用户数据报服务。

• 应用层：应用层决定了向用户提供应用服务时通信的活动。TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。
  HTTP 协议也处于该层。

TCP/IP常用协议

TCP及IP通信模型.png

不管是OSI的七层模型，还是TCP/IP的四层通用模型，在日常的开发中，我们比较关注的还是应用层跟传输层，所以接下来，重点分析一下这两层。

传输层

前面提到过，传输层有两大协议，UDP协议跟TCP协议，下面来详细分析一下：

TCP协议

按层次分，TCP 位于传输层，提供可靠的字节流服务。
所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大
块数据分割成以报文段（segment）为单位的数据包进行管理。而可
靠的传输服务是指，能够把数据准确可靠地传给对方。一言以蔽之，
TCP 协议为了更容易传送大数据才把数据分割，而且 TCP 协议能够
确认数据最终是否送达到对方。

特点

• 面向连接，“三次握手”
• 双向通信
• 保证数据按序发送，按序到达
• 超时重传

报文格式

TCP报文格式.jpg

• URG：紧急比特,当值为1时表示次报文段中有需要紧急处理。
• ACK：确认比特,值为1时确认号有效，值为0时确认号无效。
• RST：复位比特,值为1时表示TCP连接存在严重的错误，需要重新进行连接。
• SYN：同步比特,值为1表示这是一个连接请求或连接接受报文。
• FIN： 终止比特,值为1表示要发送的数据报已经发送完毕，需要释放传送连接。

通信方式

TCP建立跟断开连接.jpg

三次握手

• 第一次：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
• 第二次：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
• 第三次：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

三次握手的原因：

为了防止已经失效的连接请求报文突然又传送到服务端，因而产生错误。 减小因延迟高拥塞大对报文传输的影响。

四次挥手

• 第一次：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
• 第二次：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
• 第三次：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
• 第四次：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

四次挥手的原因：

由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。

UDP协议

报文格式

UDP报文格式.png

特点

UDP 协议没有 TCP 协议稳定，因为它不建立连接，也不按顺序发送，可能会出现丢包现象，使传输的数据出错。

但是有得就有失，UDP 的效率更高，因为 UDP 头包含很少的字节，比 TCP 负载消耗少，同时也可以实现双向通信，不管消息送达的准确率，只负责无脑发送。

UDP 服务于很多知名应用层协议，比如 NFS（网络文件系统）、SNMP（简单网络管理协议）

UDP 一般多用于 IP 电话、网络视频等容错率强的场景。

对比

• TCP是面向连接的，UDP是面向非连接的；
• TCP传输的字节流，UDP传输的数据报；
• TCP所需的系统资源相对较多，UDP需要的相对较少；
• TCP主要用于传输的较大的数据，UDP主要用于传输较小的数据；
• TCP的数据传输是可靠的，UDP的数据传输是不可靠的；

应用层(HTTP协议)

报文格式

请求报文

请求报文格式.png

通常来说HTTP请求报文由请求行（requestline）、请求头部（header）、空行、请求数据4个部分组成

• 请求行：请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1

• 请求头部：请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

常用的请求头

• 空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头

• 请求数据

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

响应报文

响应报文格式.png

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文

• 状态行：状态行由协议版本号、状态码、状态消息组成
• 响应头：响应头是客户端可以使用的一些信息
• 空行：响应头和响应体之间必须有一个空行
• 响应体：响应正文，本例中是键值对信息

状态码：

常用状态码：

200 OK                        //客户端请求成功
400 Bad Request               //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden                 //服务器收到请求，但是拒绝提供服务
404 Not Found                 //请求资源不存在
500 Internal Server Error     //服务器发生不可预期的错误
503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

常用的响应头

身份认证

HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。
Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

Cookie

定义
Cookie实际上是一小段的文本信息，客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

有效期
Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。
如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的Cookie持久化，即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑，只要还在maxAge秒之前，登录网站时该Cookie仍然有效。下面代码中的Cookie信息将永远有效。
Cookie cookie = new Cookie("username","helloweenvsfei"); // 新建Cookie
cookie.setMaxAge(Integer.MAX_VALUE); // 设置生命周期为MAX_VALUE
response.addCookie(cookie); // 输出到客户端

修改、删除
Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。
如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

Session

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

定义
session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

用户登录

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session，

生命周期

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。
Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

Socket

Socket为了实现以上的通信过程而建立成来的通信管道，其真实的代表是客户端和服务器端的一个通信进程，双方进程通过socket进行通信，而通信的规则采用指定的协议。socket只是一种连接模式，不是协议,tcp,udp，简单的说（虽然不准确）是两个最基本的协议,很多其它协议都是基于这两个协议如，http就是基于tcp的，.用socket可以创建tcp连接，也可以创建udp连接，这意味着，用socket可以创建任何协议的连接，因为其它协议都是基于此的。

使用TCP

客户端

Socket socket = new Socket("ip", 端口);
InputStream is = socket.getInputStream();
DataInputStream dis = new DataInputStream(is);

OutputStream os = socket.getOutputStream();
DataInputStream dos = new DataOutputStream(os);

服务器端

ServerSocket serverSocket = new ServerSocket(端口);
Socket socket = serverSocket.accept();
//获取流的方式与客户端一样

读取输入流

byte[] buffer = new byte[1024]; 
do{ 
    int count = is.read(buffer); 
    if(count <= 0){ break; }
    else{ 
    // 对buffer保存或者做些其他操作 
        } 
    }
while(true);

使用UDP

客户端和服务器端一样的
DatagramSocket socket = new DatagramSocket(端口);
InetAddress serverAddress = InetAddress.getbyName("ip");
//发送
DatagramPackage packet = new DatagramPacket(buffer, length, host, port);
socket.send(packet);
//接收
byte[] buf = new byte[1024];
DatagramPacket packet = new DatagramPacket(buf, 1024);
Socket.receive(packet);

HTTPS

TLS/SSL协议

HTTPS比之前提到的HTTP多了一个S，可以理解成Secure也就是安全的意思，我们知道，HTTP是明文传输的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，所以就对HTTP进行了加密，常见的加密协议有SSL跟TSL。

SSL协议

网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，

TSL协议

TLS（Transport Layer Security）是SSL 3.0的升级版，定义在RFC 2246，最初的版本是 TLS1.0。

关联

实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，TLS最新的版本是1.2，通常我们会把这两种协议统称为TLS/SSL协议。

加密算法

加密算法一般分为对称加密与非对称加密。

对称加密

客户端与服务器使用相同的密钥对消息进行加密
优点：

• 加密强度高，很难被破解
• 计算量小，仅为非对称加密计算量的 0.1%
  缺点：
• 无法安全的生成和管理密钥
• 服务器管理大量客户端密钥复杂

非对称加密

非对称指加密与解密的密钥为两种密钥。服务器提供公钥，客户端通过公钥对消息进行加密，并由服务器端的私钥对密文进行解密。
优点：安全
缺点

• 性能低下，CPU 计算资源消耗巨大，一次完全的 TLS 握手，密钥交换时的非对称加密解密占了整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%，因此如果对应用层使用非对称加密，性能开销过大，无法承受。
• 非对称加密对加密内容长度有限制，不能超过公钥的长度。比如现在常用的公钥长度是 2048 位，意味着被加密消息内容不能超过 256 字节。

加密算法

HTTPS采用的加密算法如下：

• 非对称加密算法：RSA，DSA/DSS
• 对称加密算法：AES，RC4，3DES
• HASH算法：MD5，SHA1，SHA256

工作原理

HTTPS工作原理.png

• 客户端发出请求（ClientHello）：客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求
  （1） 支持的协议版本，比如TLS 1.0版。
  （2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。
  （3） 支持的加密方法，比如RSA公钥加密。
  （4） 支持的压缩方法。
• 服务器回应（SeverHello）：服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容
  （1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  （2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。
  （3） 确认使用的加密方法，比如RSA公钥加密。
  （4） 服务器证书。
• 客户端回应：客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
  如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息:
  （1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
  （2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  （3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
• 服务器的最后回应：服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
  （1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。