简介:网络协议,7层与4层;传输层协议详解;TCP 握手;HTTP 1.0,1.1,2.0 各版本详解;序列化以及Web Service
网络协议栈
协议栈是指网络中各层协议的总和,它形象的反映了网络中消息的传输过程:即由上层应用协议到底层协议,再由底层传输协议到上层协议。
OSI七层模型
TCP/IP四层模型
联系与区别
ISO 制定的OSI 7层过于庞大,由技术人员自己开发的4层协议栈 更为广泛的应用
TCP/IP 是一个协议族,包含很多协议(UDP,TCP,IP 等见上图,命名为TCP/IP 是因为这个很重要而已)
记忆(应试会输网恋误 –> 应(应用)试(表示)会(会话)输(传输)网(网络)恋(数据链路)误(物理层))
传输层协议详解
TCP 协议
(Transmission Control Protocol 传输控制协议),是面向连接的,也就是说,在发送数据前,需要和对方建立可靠的连接。
三次握手(建立连接)
所谓三次握手(Three-Way Handshake)即建立TCP连接,就是指建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中,这一过程由客户端执行connect来触发
设主机B运行一个服务器进程,它先发出一个被动打开命令,告诉它的TCP要准备接收客户进程的连续请求,然后服务进程就处于听的状态。不断检测是否有客户进程发起连续请求,如有,作出响应。设客户进程运行在主机A中,他先向自己的TCP发出主动打开的命令,表明要向某个IP地址的某个端口建立运输连接,过程如下:
1)主机A的TCP向主机B的TCP发出连接请求报文段,其首部中的同步比特SYN应置1,同时选择一个序号x,表明在后面传送数据时的第一个数据字节的序号是x。
2)主机B的TCP收到连接请求报文段后,如同意,则发挥确认。在确认报文段中应将SYN置为1,确认号应为x+1,同时也为自己选择一个序号y
3)主机A的TCP收到此报文段后,还要向B给出确认,其确认号为y+1
4)主机A的TCP通知上层应用进程,连接已经建立,当主机B的TCP收到主机A的确认后,也通知上层应用进程,连接建立。
四次握手(断开连接)
在数据传输完毕之后,通信双方都可以发出释放连接的请求。释放连接的过程为如上图所示:
1)数据传输结束后,主机A的应用进程先向其TCP发出释放连接请求,不在发送数据。TCP通知对方要释放从A到B的连接,将发往主机B的TCP报文段首部的终止比特FIN置为1,序号u等于已传送数据的最后一个字节的序号加1。
2)主机B的TCP收到释放连接通知后发出确认,其序号为u+1,同时通知应用进程,这样A到B的连接就释放了,连接处于半关闭状态。主机B不在接受主机A发来的数据;但主机B还向A发送数据,主机A若正确接收数据仍需要发送确认。
3)在主机B向主机A的数据发送结束后,其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将终止比特置为1,并使其序号w等于前面已经传送过的数据的最后一个字节的序号加 1,还必须重复上次已发送过的ACK=u+1。
4)主机A对主机B的连接释放报文段发出确认,将ACK置为1,ACK=w+1, seq=u+1。这样才把从B到A的反方向连接释放掉,主机A的TCP再向其应用进程报告,整个连接已经全部释放。
UDP 协议
( User Data Protocol ) 用户数据协议,是一个非连接的协议,也就是说,传输数据的两端不建立连接。
- 不需要维护连接状态,因此一台服务器可同时向多个客户机传输相同数据
- UDP 信息包的标题很短,只有8个字节,TCP有20个字节信息包的开销
- UDP 尽最大可能交付,既不保证数据可靠性
- UDP 是面向报文的.如(ping 命令)
- UDP 不保证包的顺序,而TCP可保证
SCTP 协议
SCTP(Stream Control Transmission Protocol,流控制传输协议) 是IETF(因特网工程任务组)在2000年定义的一个传输层协议
简介
SCTP是一个面向连接的流传输协议,它可以在两个端点之间提供稳定、有序的数据传递服务。SCTP可以看做是TCP协议的改进,它继承了TCP较为完善的拥塞控制并改进TCP的一些不足之处
- SCTP与TCP的最大不同之处在于它是多宿主(Multi-homing)连接,而TCP是单地址连接。
- 一个TCP连接只能支持一个流,一个SCTP连接可以支持多个流(Multi-streaming)。在SCTP协议中,流(Stream)是指从一个SCTP端点到另一端点之间建立的单向逻辑通路,通常情况下所有用户消息在流中按序传递。
- SCTP有更好的安全性。
SCTP提供如下服务
- 确认用户数据的无错误和无复制传输;
- 数据分段以符合发现路径最大传输单元的大小;
- 在多数据流中用户信息的有序发送,带有一个选项,用户信息可以按到达顺序发送;
- 选择性的将多个用户信息绑定到单个SCTP包;
- 通过关联的一个终端或两个终端多重宿主支持来为网络故障规定容度。
序列化协议
protobuf,thrift,JSON,XML
protobuf 定义
Protocol Buffers是一种以有效并可扩展的格式编码结构化数据的方式
protobuf 特点
- 灵活(方便接口更新)、高效(效率经过google的优化,传输效率比普通的XML,JSON等高很多);
- 易于使用;开发人员通过按照一定的语法定义结构化的消息格式,然后送给命令行工具,工具将自动生成相关的类,可以支持java、c++、python等语言环境。通过将这些类包含在项目中,可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。
- 语言支持;原生支持c++,java,python(其他方面也有扩展,比如js)
protobuf 场景
- 内部系统之间的信息交互,并且数据大小敏感
- 小数据的交互
- 原生支持java,c++,python
- 支持向后兼容与向前兼容
protobuf 缺点
- 不能自描述,需要依赖生成的文件
- 人类不可读,由于是二进制传输,人类无法直接读取
thrift
提供了全套RPC解决方案,包括序列化机制、传输层、并发处理框架等
原生支持 C++, Java, Python, Ruby, Perl, PHP, C#, Erlang, Haskell
Web service
restful WebService
定义
RESTful 服务遵循REST(Representational State Transfer)的架构风格,中文翻译为:表现层状态转化
特点
- 网上的所有事务都可以定义为资源
- 每一个资源都有一个资源标识,对资源的操作不会改变这个标识
- 所有的操作都是无状态的
轻量级的架构体系选择(Jax-RS实现)
- Jersey + Grizzly
- Jersey + Jetty
- Dropwizard
- RESTEasy + Netty
RESTEasy + Undertow
- Jersey 官网,Grizzly官网,dropwizard
- jersey 是基于Java的一个轻量级RESTful风格的Web Services框架。
- JAX-RS 是JAVA EE6引入的一个新技术,全称:Java API fro RESTful Web Wervices ,是一个java语言的应用程序接口,支持REST风格的web服务。JAX-RS使用了JAX-RS 使用了Java SE5引入的标注来简化开发(@Path,@Produces …)
- 基于JAX-RS实现的框架有 Jersey,RESTEasy 等,可很方便的部署到Servlet容器中(Tomcat,Jboss)
- Grizzly 是一个应用程序框架,专门解决编写成千上万用户访问服务器时产生的各种问题,使用java nio作为基础,并隐藏其复杂性,当然更重要的你可以把他当成一个NIO框架(当然它是一个应用程序框架)
- Jetty 是一个开源的servlet容器,使用java编写,可嵌入性与精简性(相对于Tomcat),Jetty 属于eclipse
- dropwizard is a java framework for developing ops-friendly,high-preformance,Restful web service. (一个完整的服务框架,实际上集成了Jersey+Jetty)
- Undertow 嵌入式服务器
轻量级的架构体系选择(非Jax-RS实现)
- Spring Boot
- 纯Netty
Vert.x
较重量级的服务器
springmvc/cxf + tomcat/Jboss 等
比较结论
- RESTEasy的性能要好于Jersey
- Jersey+Grizzly2和Jersey+Jetty, dropwizard性能差别不大
- 纯netty的性能远远高于其它框架
- Vert.x 性能看起来不是太好,而且随着并发量增大吞吐率也随之下降
HTTP 协议
简介
超文本传输协议(HyperTxt Transfter Protocol) ,基于请求与响应模式的,无状态的,应用层协议,基于TCP连接
- 主要版本有 Http 1.0,1.1,2.0
- 常用的HTTP方法有 GET,POST,PUT,HEAD,DELETE,OPTIONS
- http请求与响应报文都包含3部分,起始行,消息头,消息题,CRLF作为分隔符
- 常见的状态码 略
数据传输过程
版本详解
版本发布历史
时间 | 版本 |
---|---|
1991 | HTTP/0.9 |
1996 | HTTP/1.0 |
1999 | HTTP/1.1 |
2015 | HTTP/2 |
HTTP1.0和HTTP1.1的一些区别
- 缓存处理:在1.0中主要使用header里的 If-Modified-Since,Expires 来做缓存判断,1.1引入了更多的控制策略如 Entity tag,If-Unnodifie-Since,If-Match,If-None-Match
- 带宽优化及网络连接使用:1.1 在请求头引入了 range 头域,它允许请求资源的某个部分,返回状态为 206,
- 新增的状态码(409,410)
- Host 头处理:1.1请求消息与响应消息都支持Host 头域
- 长连接:1.1支持长连接(PersistentConnection) 和请求的流水线(Pipelining) 处理,在一个TCP连接上可以传送多个请求与响应,减少建立与关闭的消耗与延迟,1.1默认开启
Google 在2012年推出过SPDY(SPeeDY) 用来优化1.1的一些不足,引起了业界强烈反响,后来互联网工程任务组(IETF)对谷歌提出的SPDY协议进行了标准化,于2015年5推出了类似于SPDY协议的 HTTP 2.0 协议标准(简称HTTP/2),这就是HTTP 2.0的由来
HTTP 2.0
- 新的二进制格式(Binary Format):1.x解析是基于文本的,2.0是居于二进制,使用更广泛
- 多路复用(MultiPlexing):及连接共享,每一个request 都是用作连接共享执行的,一个request对应一个ID,这样一个连接上可以有多个request,每个连接的request可以随机的杂糅到一起,接收方根据request的id来进行分发
- header 压缩:2.0使用encoder来减少传输的header大小
- 服务器推送(server push)
HTTP 2.0 其实可支持非 HTTPS的,但是主流游览器像chrome,firefox只支持居于TLS 的Http2.0(及HTTPS)
2.0 多路复用与1.1 长连接区别
- 1.0 一次请求,一次响应,用完关闭,新请求再建立连接
- 1.1 Pipeling 若干请求串行化,后面的请求必须要等前面的请求返回才能执行,一旦有阻塞,造成 线头阻塞
2.0 多个请求同时执行
头部压缩
一个页面有100个资源,每个请求1kb消息头,需要消耗100kb,2.0采用维护一个字典,进行差量更新,大大降低头传输