8.1.4.1. 实现步骤
1. 编写远程服务接口，该接口必须继承 java.rmi.Remote 接口，方法必须抛出 java.rmi.RemoteException 异常； 2. 编写远程接口实现类，该实现类必须继承 java.rmi.server.UnicastRemoteObject 类； 3. 运行 RMI 编译器（rmic），创建客户端 stub 类和服务端 skeleton 类; 4. 启动一个 RMI 注册表，以便驻留这些服务; 5. 在 RMI 注册表中注册服务； 6. 客户端查找远程对象，并调用远程方法； 1：创建远程接口，继承 java.rmi.Remote 接口 public interface GreetService extends java.rmi.Remote { String sayHello(String name) throws RemoteException; } 2：实现远程接口，继承 java.rmi.server.UnicastRemoteObject 类 public class GreetServiceImpl extends java.rmi.server.UnicastRemoteObject implements GreetService { private static final long serialVersionUID = 3434060152387200042L; public GreetServiceImpl() throws RemoteException { super(); } @Override public String sayHello(String name) throws RemoteException { return "Hello " + name; } } 3：生成 Stub 和 Skeleton; 4：执行 rmiregistry 命令注册服务 5：启动服务 LocateRegistry.createRegistry(1098); Naming.bind("rmi://10.108.1.138:1098/GreetService", new GreetServiceImpl()); 6.客户端调用 GreetService greetService = (GreetService) Naming.lookup("rmi://10.108.1.138:1098/GreetService"); System.out.println(greetService.sayHello("Jobs"));
8.1.5. Protoclol Buffer
protocol buffer 是 google 的一个开源项目,它是用于结构化数据串行化的灵活、高效、自动的方法， 例如 XML，不过它比 xml 更小、更快、也更简单。你可以定义自己的数据结构，然后使用代码生成器 生成的代码来读写这个数据结构。你甚至可以在无需重新部署程序的情况下更新数据结构。
8.1.5.1. 特点
Protocol Buffer 的数据压缩效果好（即序列化后的数据量体积小）的原因是：
1. 编码 / 解码 方式简单（只需要简单的数学运算 = 位移等等）
2. 采用 Protocol Buffer 自身的框架代码 和 编译器 共同完成
Protocol Buffer 的数据压缩效果好（即序列化后的数据量体积小）的原因是：
1. a. 采用了独特的编码方式，如 Varint、Zigzag 编码方式等等
2. b. 采用 T - L - V 的数据存储方式：减少了分隔符的使用 & 数据存储得紧凑
8.1.6. Thrift
Apache Thrift 是 Facebook 实现的一种高效的、支持多种编程语言的远程服务调用的框架。本文将从 Java 开发人员角度详细介绍 Apache Thrift 的架构、开发和部署，并且针对不同的传输协议和服务类 型给出相应的 Java 实例，同时详细介绍 Thrift 异步客户端的实现，最后提出使用 Thrift 需要注意的事 项。
目前流行的服务调用方式有很多种，例如基于 SOAP 消息格式的 Web Service，基于 JSON 消息格式 的 RESTful 服务等。其中所用到的数据传输方式包括 XML，JSON 等，然而 XML 相对体积太大，传输 效率低，JSON 体积较小，新颖，但还不够完善。本文将介绍由 Facebook 开发的远程服务调用框架 Apache Thrift，它采用接口描述语言定义并创建服务，支持可扩展的跨语言服务开发，所包含的代码 生成引擎可以在多种语言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等创建高效的、无缝的服务，其传输数据采用二进制格式，相对 XML 和 JSON 体积更小， 对于高并发、大数据量和多语言的环境更有优势。本文将详细介绍 Thrift 的使用，并且提供丰富的实例 代码加以解释说明，帮助使用者快速构建服务。
为什么要 Thrift：
1、多语言开发的需要 2、性能问题
9. 网络
9.1.1. 网络 7 层架构
7 层模型主要包括：
1. 物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率 等。它的主要作用是传输比特流（就是由 1、0 转化为电流强弱来进行传输,到达目的地后在转化为 1、0，也就是我们常说的模数转换与数模转换）。这一层的数据叫做比特。
2. 数据链路层：主要将从物理层接收的数据进行 MAC 地址（网卡的地址）的封装与解封装。常把这 一层的数据叫做帧。在这一层工作的设备是交换机，数据通过交换机来传输。
3. 网络层：主要将从下层接收到的数据进行 IP 地址（例 192.168.0.1)的封装与解封装。在这一层工 作的设备是路由器，常把这一层的数据叫做数据包。
4. 传输层：定义了一些传输数据的协议和端口号（WWW 端口 80 等），如：TCP（传输控制协议， 传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议， 与 TCP 特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如 QQ 聊天数据就是通过这 种方式传输的）。 主要是将从下层接收的数据进行分段进行传输，到达目的地址后在进行重组。 常常把这一层数据叫做段。
5. 会话层：通过传输层（端口号：传输端口与接收端口）建立数据传输的通路。主要在你的系统之间 发起会话或或者接受会话请求（设备之间需要互相认识可以是 IP 也可以是 MAC 或者是主机名）
6. 表示层：主要是进行对接收的数据进行解释、加密与解密、压缩与解压缩等（也就是把计算机能够 识别的东西转换成人能够能识别的东西（如图片、声音等））
7. 应用层 主要是一些终端的应用，比如说FTP（各种文件下载），WEB（IE浏览），QQ之类的（你 就把它理解成我们在电脑屏幕上可以看到的东西．就 是终端应用）。
9.1.2. TCP/IP 原理
TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层 模型方面来讲，TCP/IP 由四个层次组成：网络接口层、网络层、传输层、应用层。
9.1.2.1. 网络访问层(Network Access Layer)
1. 网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机 必须使用某种协议与网络相连。
9.1.2.2. 网络层(Internet Layer)
2. 网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网 络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也 可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特 网协议(IP，Internet Protocol)。
9.1.2.3. 传输层(Tramsport Layer-TCP/UDP)
3. 传输层(Tramsport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了 两个端到端的协议：传输控制协议(TCP，Transmission Control Protocol)和用户数据报协 议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的报文传输和对 上层应用的连接服务。为此，除了基本的数据传输外，它还有可靠性保证、流量控制、多路 复用、优先权和安全性控制等功能。UDP 是面向无连接的不可靠传输的协议，主要用于不需 要 TCP 的排序和流量控制等功能的应用程序。
9.1.2.4. 应用层(Application Layer)
4. 应用层(Application Layer)包含所有的高层协议，包括：虚拟终端协议(TELNET， TELecommunications NETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件 传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain Name
Service)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议 (HTTP，HyperText Transfer Protocol)等。
9.1.3. TCP 三次握手/四次挥手
TCP 在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般 称为“四次挥手”。
9.1.3.1. 数据包说明
1. 源端口号（ 16 位）：它（连同源主机 IP 地址）标识源主机的一个应用进程。
2. 目的端口号（ 16 位）：它（连同目的主机 IP 地址）标识目的主机的一个应用进程。这两个值 加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。
3. 顺序号 seq（ 32 位）：用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个 报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的 32 次方 － 1 后 又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该 连接的初始顺序号 ISN （ Initial Sequence Number ）。
4. 确认号 ack（ 32 位）：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当 是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为 应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必 须保持每个方向上的传输数据顺序号。
5. TCP 报头长度（ 4 位）：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这 个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然 而，没有任选字段，正常的长度是 20 字节。
6. 保留位（ 6 位）：保留给将来使用，目前必须置为 0 。
7. 控制位（ control flags ， 6 位）：在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设 置为 1 。依次为：
URG ：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
ACK ：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
PSH ：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层 而不用等待缓冲区装满。
RST ：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报 文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些 问题。
SYN ：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步（ synchronize ）。
FIN ：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
8. 窗口大小（ 16 位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源 方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。
9. 校验和（ 16 位）：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字 进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。
10. 紧急指针（ 16 位）：只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另 一端发送紧急数据的一种方式。
11. 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连 接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项， 它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充 位，使得报头长度成为整字数。
12. 数据： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报 文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数 据。在处理超时的许多情况中，也会发送不带任何数据的报文段。
9.1.3.2. 三次握手
第一次握手：主机 A 发送位码为 syn＝1,随机产生 seq number=1234567 的数据包到服务器，主机 B 由 SYN=1 知道，A 要求建立联机；
第二次握手：主机 B 收到请求后要确认联机信息，向 A 发 送 ack number=( 主 机 A 的 seq+1),syn=1,ack=1,随机产生 seq=7654321 的包
第三次握手：主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1,以及位码 ack 是否为 1，若正确，主机 A 会再发送 ack number=(主机 B 的 seq+1),ack=1，主机 B 收到后确认
9.1.3.3. 四次挥手
TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连 接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单 方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个 方向的连接。
1） 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送， 然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u
2） 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1。
3） 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
4） 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
主机 A 发送 FIN 后，进入终止等待状态， 服务器 B 收到主机 A 连接释放报文段后，就立即 给主机 A 发送确认，然后服务器 B 就进入 close-wait 状态，此时 TCP 服务器进程就通知高 层应用进程，因而从 A 到 B 的连接就释放了。此时是“半关闭”状态。即 A 不可以发送给 B，但是 B 可以发送给 A。此时，若 B 没有数据报要发送给 A 了，其应用进程就通知 TCP 释 放连接，然后发送给 A 连接释放报文段，并等待确认。A 发送确认后，进入 time-wait，注 意，此时 TCP 连接还没有释放掉，然后经过时间等待计时器设置的 2MSL 后，A 才进入到 close 状态。
9.1.4. HTTP 原理
HTTP 是一个无状态的协议。无状态是指客户机（Web 浏览器）和服务器之间不需要建立持久的连接， 这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服 务器端不保留连接的有关信息.HTTP 遵循请求(Request)/应答(Response)模型。客户机（浏览器）向 服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答。
9.1.4.1. 传输流程
1：地址解析 如用客户端浏览器请求这个页面：http://localhost.com:8080/index.htm 从中分解出协议名、主机名、 端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
协议名：http
主机名：localhost.com
端口：8080
对象路径：/index.htm
在这一步，需要域名系统 DNS 解析域名 localhost.com,得主机的 IP 地址。
2：封装 HTTP 请求数据包
把以上部分结合本机自己的信息，封装成一个 HTTP 请求数据包
3：封装成 TCP 包并建立连接
封装成 TCP 包，建立 TCP 连接（TCP 的三次握手）
4：客户机发送请求命
4）客户机发送请求命令：建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资 源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可内容。
5：服务器响应 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或 错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。
6：服务器关闭 TCP 连接 服务器关闭 TCP 连接：一般情况下，一旦 Web 服务器向浏览器发送了请求数据，它就要关闭 TCP 连 接，然后如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive，TCP 连接在发送 后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求 建立新连接所需的时间，还节约了网络带宽。
