1. 软件结构
- C/S结构：全称为Client/Server结构，是指客户端和服务器结构，常见的程序如：QQ、迅雷等
- B/S结构：全称为Browser/Server结构，是?️浏览器和服务器结构，常见浏览器有：谷歌、火狐等
两种结构各有优势，但是无论哪种结构，都离不开网络的支持，网络编程，就是在一定的协议下，实现两台计算机通信的程序。
2. 网络通信协议
我们先来看这段代码：
public class HelloWorld {
public static void main(String[] args){
System.out.println("Hello World!");
}
}作为程序员，这段代码一定都很熟悉了。其实这段代码也是一种协议，是人类和计算机沟通的协议，只有通过这种协议，计算机才知道我们想让它做什么。
协议三要素
这种协议比较接近人类语言，机器不能直接读懂，需要进行翻译，翻译的工作交给编译器，也就是compile。这个过程比较复杂，其中的编译原理非常复杂，我在这里不进行详述。
计算机语言作为程序员控制一台计算机工作的协议，具备了协议的三要素：
- 语法，就是这一段内容要符合一定的规则和格式。例如，括号要成对，结束要使用分号等。
- 语义，就是这一段内容要代表某种意义。例如数字减去数字是有意义的，数字减去文本一般来说就没有意义。
- 顺序，就是先干啥，后干啥。例如，可以先加上某个数值，然后再减去某个数值。
但是，要想打造互联网世界的通天塔，只教给一台机器做什么是不够的，你需要学会教给一大片机器做什么。这就需要网络协议。只有通过网络协议，才能使一大片机器互相协作、共同完成一件事。
举一个例子：打开浏览器输入一个网站的地址，浏览器就会展示展示该网址的页面内容。
浏览器是如何识别的呢？是因为它收到了一段来自HTTP协议的“东西”
HTTP/1.1 200 OK
Date: Tue, 27 Mar 2018 16:50:26 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: zh-CN
<!DOCTYPE html>
<html>
<head>
<base href="https://pages.kaola.com/" />
<meta charset="utf-8"/> <title>网易考拉3周年主会场</title>它符合协议的三要素：
- 符合语法，也就是说，只有按照上面那个格式来，浏览器才认。例如，上来是状态，然后是首部，然后是内容。
- 符合语义，就是要按照约定的意思来。例如，状态200，表述的意思是网页成功返回。如果不成功，就是我们常见的“404”。
- 符合顺序，你一点浏览器，就是发送出一个HTTP请求，然后才有上面那一串HTTP返回的东西。
常用的网络协议
当在浏览器里面输入 https://www.taobao.com ，这是一个URL。浏览器只知道名字是“www.taobao.com”，但是不知道具体的地点，所以不知道应该如何访问。于是，它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找，还可以使用另一种更加精准的地址簿查找协议HTTPDNS。
无论用哪一种方法查找，最终都会得到这个地址：218.98.31.235。这个是IP地址，是互联网世界的“门牌号”。
无论是HTTP协议还是HTTPS协议，里面都会写明“你要买什么和买多少”。
DNS、HTTP、HTTPS所在的层我们称为应用层。经过应用层封装后，浏览器会将应用层的包交给下一层去完成，通过socket编程来实现。下一层是传输层。传输层有两种协议，一种是无连接的协议UDP，一种是面向连接的协议TCP。所谓的面向连接就是，TCP会保证这个包能够到达目的地。如果不能到达，就会重新发送，直至到达。
TCP协议里面会有两个端口，一个是浏览器监听的端口，一个是服务器监听的端口。操作系统往往通过端口来判断，它得到的包应该给哪个进程。
传输层封装完毕后，浏览器会将包交给操作系统的网络层。网络层的协议是IP协议。在IP协议里面会有源IP地址，即浏览器所在机器的IP地址和目标IP地址，也即服务器的IP地址。
操作系统知道了目标IP地址，就开始想如何根据这个门牌号找到目标机器。就要通过网关，操作系统在启动的时候，就会被DHCP协议配置IP地址，以及默认的网关的IP地址192.168.1.1。
操作系统如何将IP地址发给网关呢？通过ARP协议，找到MAC地址。
于是操作系统将IP包交给了下一层，也就是MAC层。网卡再将包发出去。由于这个包里面是有MAC地址的，因而它能够到达网关。
网关收到包之后，会根据自己的知识，判断下一步应该怎么走。网关往往是一个路由器，到某个IP地址应该怎么走，这个叫作路由表。
路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家，每个国家相当于一个局域网，在每个国家内部，都可以使用本地的地址MAC进行通信。
一旦跨越城关，就需要拿出IP头来，里面写着贫僧来自东土大唐（就是源IP地址），欲往西天拜佛求经（指的是目标IP地址）。路过宝地，借宿一晚，明日启行，请问接下来该怎么走啊？
城关往往是知道这些“知识”的，因为城关和临近的城关也会经常沟通。到哪里应该怎么走，这种沟通的协议称为路由协议，常用的有OSPF和BGP。
七层网络模型OSI和TCP/IP四层模型对比：
3. 协议分类
通信的协议还是比较复杂的，java.net包中包含的类和接口，它们提供封装了底层的通信细节，可以直接使用这些类和接口，专注网络程序开发，而不用考虑通信细节。
传输层里比较重要的两个协议：一个是TCP，一个是UDP。对于日常开发来说，最常用的就是这两个协议。
3.1 UDP协议
那么TCP和UDP有哪些区别呢？一般在面试的时候问这两个协议的区别，大部分人会回答，TCP是面向连接的，UDP是面向无连接的。然后就没有了～～～
什么叫面向连接，什么叫无连接呢？在互通之前，面向连接的协议会先建立连接。例如，TCP会三次握手，而UDP不会。那为什么要建立连接呢？你TCP三次握手，我UDP也可以发三个包玩玩，有什么区别吗？
所谓的建立连接，是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据结构来保证所谓的面向连接的特性。
- TCP提供可靠交付。通过TCP连接传输的数据，无差错、不丢失、不重复、并且按序到达。我们都知道IP包是没有任何可靠性保证的，一旦发出去，都只能随它去。而UDP继承了IP包的特性，不保证不丢失，不保证按顺序到达。
- TCP是面向字节流的。发送的时候发的是一个流，没头没尾。IP包可不是一个流，而是一个个的IP包。之所以变成了流，这也是TCP自己的状态维护做的事情。而UDP继承了IP的特性，基于数据报的，一个一个地发，一个一个地收。
- TCP是可以有拥塞控制的。它意识到包丢弃了或者网络的环境不好了，就会根据情况调整自己的行为，看看是不是发快了，要不要发慢点。UDP就不会，应用让我发，我就发。
- TCP其实是一个有状态服务，通俗地讲就是有脑子的，里面精确地记着发送了没有，接收到没有，发送到哪个了，应该接收哪个了，错一点儿都不行。而UDP则是无状态服务。通俗地说是没脑子的，天真无邪的，发出去就发出去了。
UDP包头是什么样的？
我们自己知道发的是一个UDP的包，而收到的那台机器咋知道的呢？在IP头里面有个8位协议，这里会存放，数据里面到底是TCP还是UDP，当然这里是UDP。于是，如果我们知道UDP头的格式，就能从数据里面，将它解析出来。解析出来以后呢？数据给谁处理呢？
处理完传输层的事情，内核的事情基本就干完了，里面的数据应该交给应用程序自己去处理，可是一台机器上跑着这么多的应用程序，应该给谁呢？
无论应用程序写的使用TCP传数据，还是UDP传数据，都要监听一个端口。正是这个端口，用来区分应用程序，要不说端口不能冲突呢。两个应用监听一个端口，到时候包给谁呀？所以，按理说，无论是TCP还是UDP包头里面应该有端口号，根据端口号，将数据交给相应的应用程序。
UDP包最大长度计算：
从图中可知：使用16位（2个字节）存储长度信息，可以存储2^16=64k-1=65536-1=65535，自身协议占用16位+16位+16位+16位=64位=8个字节，UDP包最大长度为：65535-8=65507 byte
UDP的三大特点：
- 沟通简单，不需要一肚子花花肠子（大量的数据结构、处理逻辑、包头字段）。前提是它相信网络世界是美好的，秉承性善论，相信网络通路默认就是很容易送达的，不容易被丢弃的。
- 轻信他人。它不会建立连接，虽然有端口号，但是监听在这个地方，谁都可以传给他数据，他也可以传给任何人数据，甚至可以同时传给多个人数据。
- 愣头青，做事不懂权变。不知道什么时候该坚持，什么时候该退让。它不会根据网络的情况进行发包的拥塞控制，无论网络丢包丢成啥样了，它该怎么发还怎么发。
UDP的三大使用场景：
- 需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用
- 不需要一对一沟通，建立连接，而是可以广播的应用。UDP的不面向连接的功能，可以使得可以承载广播或者多播的协议。DHCP就是一种广播的形式，就是基于UDP协议的。
对于多播，其中D类地址为多播预留，使用这个地址，可以将包多播给一批机器。
- 需要处理速度快，时延低，可以容忍少数丢包，但是要求即便网络拥塞，也毫不退缩，一往无前的时候。
UDP简单、处理速度快，不像TCP那样，操这么多的心，各种重传啊，保证顺序啊，前面的不收到，后面的没法处理啊。不然等这些事情做完了，时延早就上去了。而TCP在网络不好出现丢包的时候，拥塞控制策略会主动的退缩，降低发送速度，这就相当于本来环境就差，还自断臂膀，用户本来就卡，这下更卡了。
3.2 TCP协议
传输控制协议TCP简介：
- 面向连接的，可靠的，基于字节流的传输层通信协议
- 将应用层的数据流分割成报文段并发送给目标节点的TCP层
- 数据报都有序号，对方收到将发送ACK确认，未收到则重传
- 使用校验和校验数据在传输过程中是否有误
TCP包头格式
先来看TCP头的格式。从这个图上可以看出，它比UDP复杂得多。
首先，源端口号和目标端口号是不可少的，这一点和UDP是一样的。如果没有这两个端口号。数据就不知道应该发给哪个应用。
接下来是包的序号。为什么要给包编号呢？当然是为了解决乱序的问题。不编好号怎么确认哪个应该先来，哪个应该后到呢。编号是为了解决乱序问题。
还应该有的就是确认序号。发出去的包应该有确认，要不然我怎么知道对方有没有收到呢？如果没有收到就应该重新发送，直到送达。这个可以解决不丢包的问题。
TCP是靠谱的协议，但是这不能说明它面临的网络环境好。从IP层面来讲，如果网络状况的确那么差，是没有任何可靠性保证的，而作为IP的上一层TCP也无能为力，唯一能做的就是更加努力，不断重传，通过各种算法保证。也就是说，对于TCP来讲，IP层你丢不丢包，我管不着，但是我在我的层面上，会努力保证可靠性。
接下来有一些状态位。例如：URG是紧急指针标志；SYN是同步序号标志，用于建立连接过程；ACK是回复，确认序号标志；PSH是push标志；RST是重新连接；FIN是finish标志，用于释放连接等。TCP是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方的状态变更。
还有一个重要的就是窗口大小。TCP要做流量控制，通信双方各声明一个窗口，标识自己当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。
除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。
通过对TCP头的解析，我们知道要掌握TCP协议，重点应该关注以下几个问题：
- 顺序问题 ，稳重不乱；
- 丢包问题，承诺靠谱；
- 连接维护，有始有终；
- 流量控制，把握分寸；
- 拥塞控制，知进知退。
TCP的三次握手
握手是为了建立连接，TCP三次握手流程如下：
在TCP/IP协议中，TCP协议提供可靠的连接服务，通过三次握手建立连接：
- 第一次握手：建立连接时，服务端发送SYN包（seq=x）到服务器，并进入SYN-SENT状态，等待服务器确认
- 第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN-RCVD状态
- 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=y+1），此包发送完毕，客户端与服务器进入ESTABLISHED状态，完成三次握手。
一开始，客户端和服务端都处于CLOSED状态。先是服务端主动监听某个端口，处于LISTEN状态。然后客户端主动发起连接SYN，之后处于SYN-SENT状态。服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态。客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态，因为它一发一收成功了。服务端收到ACK的ACK之后，处于ESTABLISHED状态，因为它也一发一收了。
1、为什么要三次，而不是两次？按说两个人打招呼，一来一回就可以了啊？为了可靠，为什么不是四次？
假设A和B之间通信，A要发起一个连接，当发了第一个请求杳无音信的时候，会有很多的可能性，比如第一个请求包丢了，再如没有丢，但是绕了弯路，超时了，还有B没有响应，不想和我连接。
A不能确认结果，于是再发，再发。终于，有一个请求包到了B，但是请求包到了B的这个事情，目前A还是不知道的，A还有可能再发。
B收到了请求包，就知道了A的存在，并且知道A要和它建立连接。如果B不乐意建立连接，则A会重试一阵后放弃，连接建立失败，没有问题；如果B是乐意建立连接的，则会发送应答包给A。
当然对于B来说，这个应答包也是不知道能不能到达A。这个时候B自然不能认为连接是建立好了，因为应答包仍然会丢，会绕弯路，或者A已经挂了都有可能。因而两次握手肯定不行。
如果A就是不发数据，建立连接后空着。在程序设计的时候，可以要求开启keepalive机制，即使没有真实的数据包，也有探活包。
另外，作为服务端B的程序设计者，对于A这种长时间不发包的客户端，可以主动关闭，从而空出资源来给其他客户端使用。
三次握手除了双方建立连接外，主要还是为了沟通一件事情，就是TCP包的序号的问题。（为了初始化Sequence Number初始化）
TCP四次挥手
TCP采用四次挥手释放连接：
- 第一次挥手：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进入CLOSE状态，完成四次挥手。
挥手就是终止连接，TCP四次挥手的流程图：
断开的时候，我们可以看到，当A说“不玩了”，就进入FIN_WAIT_1的状态，B收到“A不玩”的消息后，发送知道了，就进入CLOSE_WAIT的状态。
A收到“B说知道了”，就进入FIN_WAIT_2的状态，如果这个时候B直接跑路，则A将永远在这个状态。TCP协议里面并没有对这个状态的处理，但是Linux有，可以调整tcp_fin_timeout这个参数，设置一个超时时间。
如果B没有跑路，发送了“B也不玩了”的请求到达A时，A发送“知道B也不玩了”的ACK后，从FIN_WAIT_2状态结束，按说A可以跑路了，但是最后的这个ACK万一B收不到呢？则B会重新发一个“B不玩了”，这个时候A已经跑路了的话，B就再也收不到ACK了，因而TCP协议要求A最后等待一段时间TIME_WAIT，这个时间要足够长，长到如果B没收到ACK的话，“B说不玩了”会重发的，A会重新发一个ACK并且足够时间到达B。
A直接跑路还有一个问题是，A的端口就直接空出来了，但是B不知道，B原来发过的很多包很可能还在路上，如果A的端口被一个新的应用占用了，这个新的应用会收到上个连接中B发过来的包，虽然序列号是重新生成的，但是这里要上一个双保险，防止产生混乱，因而也需要等足够长的时间，等到原来B发送的所有的包都死翘翘，再空出端口来。
等待的时间设为2MSL，MSL是Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为TCP报文基于是IP协议的，而IP头中有一个TTL域，是IP数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。协议规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
还有一个异常情况就是，B超过了2MSL的时间，依然没有收到它发的FIN的ACK，怎么办呢？按照TCP的原理，B当然还会重发FIN，这个时候A再收到这个包之后，A就表示，我已经在这里等了这么长时间了，已经仁至义尽了，之后的我就都不认了，于是就直接发送RST，B就知道A早就跑了。
1、为什么会有TIME_WAIT状态？
- 确保有足够的时间让对方收到ACK包
- 避免新旧连接混淆
4 基于TCP和UDP协议的Socket编程
Socket编程进行的是端到端的通信，往往意识不到中间经过多少局域网，多少路由器，因而能够设置的参数，也只能是端到端协议之上网络层和传输层的。
在网络层，Socket函数需要指定到底是IPv4还是IPv6，分别对应设置为AF_INET和AF_INET6。另外，还要指定到底是TCP还是UDP。还记得咱们前面讲过的，TCP协议是基于数据流的，所以设置为SOCK_STREAM，而UDP是基于数据报的，因而设置为SOCK_DGRAM。
4.1 基于TCP协议的Socket程序函数调用过程
TCP的服务端要先监听一个端口，一般是先调用bind函数，给这个Socket赋予一个IP地址和端口。
为什么需要端口呢？
要知道，你写的是一个应用程序，当一个网络包来的时候，内核要通过TCP头里面的这个端口，来找到你这个应用程序，把包给你。
为什么要IP地址呢？
有时候，一台机器会有多个网卡，也就会有多个IP地址，你可以选择监听所有的网卡，也可以选择监听一个网卡，这样，只有发给这个网卡的包，才会给你。
当服务端有了IP和端口号，就可以调用listen函数进行监听。在TCP的状态图里面，有一个listen状态，当调用这个函数之后，服务端就进入了这个状态，这个时候客户端就可以发起连接了。
在内核中，为每个Socket维护两个队列。一个是已经建立了连接的队列，这时候连接三次握手已经完毕，处于established状态；一个是还没有完全建立连接的队列，这个时候三次握手还没完成，处于syn_rcvd的状态。
接下来，服务端调用accept函数，拿出一个已经完成的连接进行处理。如果还没有完成，就要等着。
在服务端等待的时候，客户端可以通过connect函数发起连接。先在参数中指明要连接的IP地址和端口号，然后开始发起三次握手。内核会给客户端分配一个临时的端口。一旦握手成功，服务端的accept就会返回另一个Socket。
监听的Socket和真正用来传数据的Socket是两个，一个叫作监听Socket，一个叫作已连接Socket。
连接建立成功之后，双方开始通过read和write函数来读写数据，就像往一个文件流里面写东西一样。
这个图就是基于TCP协议的Socket程序函数调用过程:
4.2 基于UDP协议的Socket程序函数调用过程
对于UDP来讲，过程有些不一样。UDP是没有连接的，所以不需要三次握手，也就不需要调用listen和connect，但是，UDP的的交互仍然需要IP和端口号，因而也需要bind。UDP是没有维护连接状态的，因而不需要每对连接建立一组Socket，而是只要有一个Socket，就能够和多个客户端通信。也正是因为没有连接状态，每次通信的时候，都调用sendto和recvfrom，都可以传入IP地址和端口。
这个图的内容就是基于UDP协议的Socket程序函数调用过程:
4.3 服务器最大连接数
先来算一下理论值，也就是最大连接数，系统会用一个四元组来标识一个TCP连接。
{本机IP, 本机端口, 对端IP, 对端端口}服务器通常固定在某个本地端口上监听，等待客户端的连接请求。因此，服务端端TCP连接四元组中只有对端IP, 也就是客户端的IP和对端的端口，也即客户端的端口是可变的，因此，最大TCP连接数=客户端IP数×客户端端口数。对IPv4，客户端的IP数最多为2的32次方，客户端的端口数最多为2的16次方，也就是服务端单机最大TCP连接数，约为2的48次方。
当然，服务端最大并发TCP连接数远不能达到理论上限。首先主要是文件描述符限制，Socket都是文件，所以首先要通过ulimit配置文件描述符的数目；另一个限制是内存，每个TCP连接都要占用一定内存，操作系统是有限的。
如果我的文章对您有帮助，不妨点个赞鼓励一下(^_^)
android
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。