Java 网络编程_java网络编程

1 网络编程概述

• 网络编程的本质是多台计算机之间的数据交换。
• 数据传递本身没有多大的难度，不就是把一个设备中的数据发送给其他设备，然后接受另外一个设备反馈的数据。
• 现在的网络编程基本上都是基于请求/响应方式的，也就是一个设备发送请求数据给另外一个，然后接收另一个设备的反馈。
• 在网络编程中，发起连接程序，也就是发送第一次请求的程序，被称作客户端(Client)，等待其他程序连接的程序被称作服务器(Server)。
• 客户端程序可以在需要的时候启动，而服务器为了能够时刻相应连接，则需要一直启动。

1.1 网络协议

在计算机网络要做到井井有条的交换数据，就必须遵守一些事先约定好的规则，比如交换数据的格式、是否需要发送一个应答信息。这些规则被称为网络协议。

2 网络模型

2.1 OSI七层网络模型

2.2 TCP/IP五层模型

2.3 每层对应的协议

• TCP/IP：传输控制/网络协议，是面向连接的协议，发送数据前要先建立连接(发送方和接收方的成对的两个之间必须建 立连接)，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达。

• UDP：UDP它是属于TCP/IP协议族中的一种。是无连接的协议，发送数据前不需要建立连接，是没有可靠性的协议。因为不需要建立连接所以可以在在网络上以任何可能的路径传输，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。

• http：Http协议是对客户端和服务器端之间数据之间实现可靠性的传输文字、图片、音频、视频等超文本数据的规范，格式简称为“超文本传输协议”。

• Https：Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

2.3.1 HTTPS工作原理

1、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
2、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）；
3、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
4、发送给服务端，此时只有服务端（RSA私钥）能解密。
5、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）

2.3.2 TCP三次握手连接

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

完成三次握手，随后Client与Server之间可以开始传输数据了。

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

2.3.3 TCP四次挥手释放

• 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
• 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
• 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
• 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

2.3.4 TCP 协议如何来保证传输的可靠性

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。

对于可靠性，TCP通过以下方式进行保证：

• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；

• 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；

• 丢弃重复数据：对于重复数据，能够丢弃重复数据；

• 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

• 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

• 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

2.3.5 TCP 粘包

粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。只有TCP有粘包现象，UDP不会。

产生原因：
当连续发送数据时，由于tcp协议的nagle算法，会将较小的内容拼接成大的内容，一次性发送到服务器端，因此造成粘包当发送内容较大时，由于服务器端的recv（buffer_size）方法中的buffer_size较小，不能一次性完全接收全部内容，因此在下一次请求到达时，接收的内容依然是上一次没有完全接收完的内容，因此造成粘包现象。

解决办法：
在每次使用tcp协议发送数据流时,在开头标记一个数据流长度信息，并固定该报文长度(自定义协议)。在客户端接收数据时先接收该长度字节数据，判断客户端发送数据流长度，并只接收该长度字节数据，就可以实现拆包，完美解决tcp粘包问题。

3 SOCKET 编程

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个外观模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

典型的TCP客户端要经过下面三步操作：

1、创建一个Socket实例：构造函数向指定的远程主机和端口建立一个TCP连接；
2、通过套接字的I/O流与服务端通信；
3、使用Socket类的close方法关闭连接。
1
2
3

典型的TCP服务端执行如下两步操作：

1、创建一个ServerSocket实例并指定本地端口，用来监听客户端在该端口发送的TCP连接请求；
2、重复执行：
	1）调用ServerSocket的accept（）方法以获取客户端连接，并通过其返回值创建一个Socket实例；
	2）为返回的Socket实例开启新的线程，并使用返回的Socket实例的I/O流与客户端通信；
	3）通信完成后，使用Socket类的close（）方法关闭该客户端的套接字连接。
1
2
3
4
5

4 HTTP

4.1 HTTP 请求所经历的步骤

• 1、建立TCP连接；
• 2、Web浏览器向Web服务器发送请求行：一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /test/hello/1.1。
• 3、Web浏览器发送请求头：浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
• 4、Web服务器应答：客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
• 5、Web服务器发送应答头：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
• 6、Web服务器向浏览器发送数据：Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
• 7、Web服务器关闭TCP连接。

通俗描述：
1、由域名→IP地址 寻找IP地址的过程依次经过了浏览器缓存、系统缓存、hosts文件、路由器缓存、 递归搜索根域名服务器。
2、建立TCP/IP连接（三次握手具体过程）
3、由浏览器发送一个HTTP请求
4、经过路由器的转发，通过服务器的防火墙，该HTTP请求到达了服务器。
5、服务器处理该HTTP请求，返回一个HTML文件。
6、浏览器解析该HTML文件，并且显示在浏览器端。

4.2 HTTP 协议无状态协议

HTTP 是一个无状态的协议，也就是没有记忆力，这意味着每一次的请求都是独立的，缺少状态意味着如果后续处理需要前面的信息，则它必须要重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就很快。

HTTP 的这种特性有优点也有缺点：

• 优点：解放了服务器，每一次的请求“点到为止”，不会造成不必要的连接占用。
• 缺点：每次请求会传输大量重复的内容信息，并且，在请求之间无法实现数据的共享。

解决方案：

• 使用参数传递机制：将参数拼接在请求的 URL 后面，实现数据的传递（GET方式），例如： /param/list?username=wmyskxz
  问题：可以解决数据共享的问题，但是这种方式一不安全，二数据允许传输量只有1kb。
• 使用 Cookie 技术
• 使用 Session 技术

4.2.1 Cookie

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

4.2.2 Session

• 会话状态也可以保存在服务器端。
• 客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；
• 如果客户端请求不包sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。
• 保存这个sessionid的方式可以采用 cookie机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；
• 若浏览器禁用Cookie的话，可以通过 URL重写机制将sessionid传回服务器。

4.2.2 Cookie 和 Session 的区别

实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关；
安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全；
服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

5 Tomcat

5.1 Tomcat 概述

• 服务器: 就是一台电脑。
• web服务器：就是一台电脑上装了一个软件，用户可以通过浏览器访问这上面的资源。
• Tomcat服务器：就是一个软件，是一个轻量级的web应用服务器。如果你的程序想要被用户访问，那么这个程序必须放入Tomcat中。

5.2 Tomcat和Servlet的关系

• Tomcat 是Web应用服务器，是一个Servlet/JSP容器。
• Tomcat 作为Servlet容器，负责处理客户请求，把请求传送给Servlet，并将Servlet的响应传送回给客户。
• 而Servlet是一种运行在支持Java语言的服务器上的组件。
• Servlet最常见的用途是扩展Java Web服务器功能，提供非常安全的，可移植的，易于使用的CGI替代品。

①：Tomcat将http请求文本接收并解析，然后封装成HttpServletRequest类型的request对象，所有的HTTP头数据读可以通过request对象调用对应的方法查询到。

②：Tomcat同时会要响应的信息封装为HttpServletResponse类型的response对象，通过设置response属性就可以控制要输出到浏览器的内容，然后将response交给tomcat，tomcat就会将其变成响应文本的格式发送给浏览器

Java Servlet API 是Servlet容器(tomcat)和servlet之间的接口，它定义了serlvet的各种方法，还定义了Servlet容器传送给Servlet的对象类，其中最重要的就是ServletRequest和ServletResponse。所以说我们在编写servlet时，需要实现Servlet接口，按照其规范进行操作。

5.3 Tomcat 调优

1. 禁用AJP服务：修改conf下的server.xml文件

<!-- <connector port="8009" protocal="AJP/1.3" redirectPort="8443" /> -->
1

2. 调整Excutor线程池参数

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="500" minSpareThreads="50" maxQueueSize="1000"/>
1
2

maxThreads：最大线程并发线程数；默认200
minSpareThreads：初始化创建线程数，默认25
maxQueueSize：最大的等待队列，超过则拒绝请求

3. 调整Tomcat运行模拟

• bio：默认的模式，性能非常低下，没有经过任何优化处理和支持。
• nio：nio（new I/O），是Java SE 1.4及后续版本提供的一种新的I/O操作方式（既java.nio包及其子包）。Java nio是一个基于缓冲区、并能提供非阻塞I/O操作的Java API，因此nio也被看成是non-blocking I/O的缩写。它拥有比传统I/O操作（bio）更好的并发运行 性能。
• apr：安装起来最困难，但是从操作系统级别来解决异步的IO问题，大幅度的提高性能。

推荐使用nio，不过，在tomcat8中有最新的nio2，速度更快，建议使用nio2。

<Connector port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol"
               connectionTimeout="20000"
               redirectPort="8443" />
1
2
3

6 高并发高解决方案

1. 页面静态化。
2. CDN缓存：内容分发网络。
3. 文件服务器分离
4. 数据库集群、分库分表
5. 缓存
6. 分布式应用