作为一名后端屌丝程序员，对算法、并发、性能乐此不疲。但是，随着年龄和阅历的增加，显然叶落而不知秋的心态是不太能混了。尤其是，某T面试官在明知我是后端，且明确表示对HTTP协议不太熟的情况下，强行让我解释HTTP状态码200至600的含义。这，便是本篇的初衷，讲一讲后端眼里的前端故事。内容基于《深入分析JavaWeb技术内幕》，加入了自己的理解，思维会比较跳跃，需要后端基础。
web请求过程
作为一名从CS架构转入BS架构的后端，不得不说，BS是趋势也是方向，两个好处：
- 客户端使用统一的浏览器，使用配置简单
- 服务端基于统一的HTTP，简化开发模式，并且开源服务器众多，开发成本低
B/S网络架构
CS架构通常是长链接交互数据，而BS架构是通过基于HTTP协议的无状态的短链接通讯。当在浏览器输入http://www.cnblogs.com/1024Community/时，会发生一系列动作，最终将需要的信息返回到浏览器。其中涉及很多概念，如DNS解析、CDN、负载均衡等（后续会详解），但是基本架构还是差不多，基本流程是：
浏览器输入URL---DNS解析成对应IP---负载均衡服务器---CDN---服务端系统---分布式缓存---文件系统/DB
包含CDN的架构图：
发起一个HTTP请求
概括为，通过URL解析到服务器IP，建立socket链接，发送符合HTTP规范的输入流，等待服务器返回数据，然后断开链接。linux中curl+URL命令，可以简单发起一个HTTP请求。
HTTP解析
HTTP是BS网络架构的核心，程序员杀人放火之必备。
首先，要了解的是HTTP header部分，它控制着数据传输、浏览器渲染、服务器执行逻辑。
常见HTTP请求头：
常见响应头：
常见错误码：
总结：
HTTP请求头，charset、encoding、language、host、User-Agent、Connection
HTTP响应头，Server、type、encoding、language、length、Keep-Alive
HTTP常见状态码，200成功，302临时跳转，400请求语法错误，403服务器收到请求，拒绝服务，404请求资源不存在，500服务端异常
浏览器缓存机制
复杂而又重要，常用ctrl+F5组合键刷新界面，来获得最新数据。其原理是，在header中添加了两项，Pragma:no-cache和Cache-Control:no-cache。对于缓存相关的header参数，主要如下：
Pragma／Cache-Control
缓存控制，Cache-Control优先级较高，和其他请求字段同时存在时（如Expires），会覆盖其他字段。Pragma类似，常用就是Pragma:no-cache,可选值如下：Expires
指定一个日期，超过这个日期，缓存超时，重新请求Last-Modified／Etag
服务端响应头中返回一个Last-Modified字段，告诉浏览器这个页面的最后修改时间。当浏览器再次请求时，在header中添加If-Modified-Since字段，来询问页面是否最新，最新则返回304，服务器也不会传送数据。
Etag类似功能，为每一个页面分配一个唯一编号，后端比较难处理，需要记住网站所有资源。
DNS域名解析
将域名解析成地址，非常重要。整个HTTP通信都是基于TCP／IP协议簇的，没有IP地址就没法通信，但是IP地址是一串数字，难记，所以有了IP和域名的对应关系。有了对应关系，就要有解析，知道域名通过对应关系，就能得到IP，从而建立起通信。
DNS域名解析过程
看书说话，我们来捋一捋，当你在浏览器输入一串URL时，怎么找到的对应服务器IP
- 浏览器检查本地缓存，缓存有实效，通过TTL（DNS记录在DNS服务器上缓存时间）设置
- 检查操作系统缓存，linux下在/etc/hosts
- 本地区域名服务器，LDNS
- Root Server域名服务器
- 根域名服务器返回给本地域名服务器一个所查询域的主域名服务器gTLD Server地址（全球13台左右）
- LDNS在向上一步gTLD发送请求
- 接收请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器地址（通常是注册的域名（提供商）服务器）
- Name Server查询存储的域名和IP映射关系，连同一个TTL值返回给DNS Server
- 返回该域名对应的IP和TTL值，LDS会缓存这个对应关系
- 把解析结果返回给用户，用户根据TTL值缓存在本地
Tips：win下使用nslookup，linux使用dig查询解析过程。 两个缓存地方LDS和本地机器，可用命令刷新，JVM也会缓存DNS结果，使用InetAddress时，注意使用单例模式，避免性能问题。
CDN工作机制
Content Delivery Network（内容分布网络）类似镜像+缓存+整体LB，通常缓存静态资源，用户主站取动态数据，CDN下载静态数据。目标：可扩展，安全性，可靠性。
CDN架构
看图说话，通过域名解析，通常会CNAME到CDN全局中的DNS负载均衡服务器，在通过这个GTM（广域网流量管理）分配到离用户最近的CDN节点。用户就可以到这个节点访问静态文件了。
负载均衡
负载均衡，分为链路LB（DNS解析成不同IP）、集群LB（分为硬件和软件，硬件贵，性能好，但不能动态扩容，如F5；软件LB，如LVS）、操作系统LB（软中断和硬件中断，如多队列网卡）。
CDN动态加速
总结为，通过CDN的DNS解析中通过动态的链路探测寻找回源最佳路径，然后通过DNS调度将所有请求调度到选定的路径上回源，加速用户访问效率
Java I／O的工作机制
Java I／O类库的基本架构
IO问题是人机交互的核心问题，是获取和交换信息的渠道，向来是应用系统的瓶颈，Java也在持续优化，如1.4版本引入了NIO。整个java.io包几十个类，有些概念不再详细介绍了（如字节流、字符流、io包继承结构），总体上看IO大体分为：
- 基于字节操作的io接口：InputStream和OutputStream
- 基于字符操作的io接口：Writer和Reader
- 基于磁盘操作的io接口：File
- 基于网络操作的io接口：Socket（也算是IO）
字节和字符的转化
首先，数据持久化或网络传输都是以字节进行的，这就涉及一个字符和字节转化的问题，其中最重要的就是字符集编码问题，否则很容易出现常见的乱码问题，字符解码类图如下：
其中InputStreamReader类是从字节到字符转化桥梁，过程中要指定字符集，否则使用操作系统默认。
补充个UML知识，上图中使用的是组合，是整体与部分的关系，代码实现就是成员变量，如下
读的时候，字节流转化为字符，要解码（StreamDecoder），同样道理，写入是从字符到字节，需要编码（StreamEncoder）
磁盘IO工作机制
几种访问文件方式
访问文件，读取和写入是调用操作系统的IO接口，因为磁盘是由操作系统管理。而只要是系统调用就会存在内核空间和用户空间切换问题，这本身是操作系统保护本身运行安全的机制，这就会出现一个问题，内核空间和用户空间的数据复制，由于内核空间访问快，用户空间访问慢，所以，出现了缓存。这是基本原理，几种访问文件方式如下：
- 标准访问文件方式（实际上读写都是和内核空间缓存打交道，什么时候刷新到磁盘由操作系统决定）
- 直接IO方式（内核不缓存，直接和磁盘IO打交道，慢，通常结合异步IO提升性能）
- 同步访问文件（和标准访问类似，但是等缓存数据刷新到磁盘，才返回给应用）
- 异步访问方式（访问发出后，不阻塞，异步返回）
- 内存映射方式（把内核空间和磁盘文件关联，共享数据，减少
数据复制操作）
Java访问磁盘文件
File对象是个虚拟的描述，解码类StreamDecoder、真正的文件描述类FileDescriptor，一图胜万言，如下，
Java序列化技术
序列化就是将一个对象转为为一串二进制的字节数组，通过保存或转移这些字节数据来达到持久化的目的。接口，java.io.Serializable。
对象序列化之后，查看二进制数组，会包含序列化协议、版本、是否新对象、class完整类名、UID、标记、所含域的个数、域类型、域名城、父类信息、类各属性的实际值。
几个Java序列化要点：
- 父类继承Serializable接口时，所有子类可序列化
- 子类实现Serializable接口时，父类没有，则只有字类的属性可序列化（不报错）
- 如果序列化的属性是对象，则这个对象也必须实现Serializable接口，否则报错
- 反序列化时，如果对象属性有修改或删减，修改的属性部分会丢失，不报错
- 反序列化时，UID被修改，会失败
纯Java环境，序列化可以很好的工作。多语言环境见还是推荐使用通用的数据结构如XML、JSON。
网络IO机制
TCP三次握手和四次挥手
TCP建立过程，三次握手和四次挥手，过程如下：
两个问题：
为什么A还要发送一次确认呢？可以二次握手吗？
为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
Java Socket工作机制
底层TCP／IP协议，Socket和ServerSocket（accept之前是阻塞的）建立连接，通过字节流传输，传输过程中，操作系统会为InputStream和OutputStream分配一定大小缓冲区，数据读写通过缓冲区完成。
NIO概述
BIO方式，不管是网络还是磁盘，一旦有阻塞，线程都会失去CPU使用权。当需要大量HTTP长链接的情况，或者提升个别IO请求优先级，或者竞态资源同步，BIO处理起来会非常复杂，此时，NIO闪亮登场。显然，这个话题需要一个崭新的大篇幅来介绍，此处省略一万字=。=
IO调优
- 磁盘IO优化
- 增加缓存，减少磁盘访问次数
- 优化磁盘管理系统，设计最优的磁盘寻址策略（太底层）
- 设计合理的磁盘存储数据块
- 应用合理的RAID策略提升磁盘IO- TCP网络参数调优
- 32位系统通常只有65535个端口，0～1024受保护，查看可用端口数量，较少时可以通过更改tcp_fin_timeout位更小的值来快速释放。常用信息：
cat ／proc／net／netstat ：查看TCP统计信息
cat ／proc／net／snmp ：查看当前系统连接情况
netstat -s ：查看网络统计信息 - 网络IO优化
- 减少网络交互次数
- 减少网络传输数据量大小
- 减少编码（重要，网络流是字节形式，字符转字节比较耗时，尽量以字节形式传输或提前转码）
- 同步和异步的选择（同步就是一个任务的完成需要依赖另外一个任务的完成）
- 阻塞与非阻塞的选择（阻塞就是CPU停下来等待一个慢的操作完成才接着完成其他的工作）
- 同步、异步、阻塞、非阻塞混搭组合（根据场景来选择）IO涉及的设计模式
以下高能，需要功底：
适配器模式，关键点：Adapter完成源到目标的适配，一般是继承源或持有源（构造器注入、方法注入等），实现目标接口。
装饰器模式，关键点：在不改变源的接口的情况下，进行功能扩展。io包InputStream各种装饰器（FilterInputStream、BufferedInputStream等）通过持有源（构造器注入）来完成功能扩展。
两者都对类进行了包装，两者的本质区别在于是否改变了源的接口。
后续篇Java NIO在这里，Java NIO
以上来自天团运营总监：坤少