计算机基础——网络基础_client hello

七层模型

TCP/IP

封装过程中，经过TCP/UDP层的时候，会把端口号添加到TCP/UDP首部；经过IP层的时候，会把协议类型（TCP or UDP or ICMP or IGMP）添加到IP首部；经过链路层的时候，会把帧类型（IP or ARP or RARP）添加到以太网首部。这些信息将被用于接收端的处理。

标识位

标志位总共分为6类，如下：

SYN(synchronous)： 发送/同步标志，用来建立连接，和下面的第二个标志位ACK搭配使用。连接开始时，SYN=1，ACK=0，代表连接开始但是未获得响应。当连接被响应的时候，标志位会发生变化，其中ACK会置为1，代表确认收到连接请求，此时的标志位变成了 SYN=1，ACK=1。
ACK(acknowledgement)：确认标志，表示确认收到请求。
PSH(push) ：表示推送操作，就是指数据包到达接收端以后，不对其进行队列处理，而是尽可能的将数据交给应用程序处理；
FIN(finish)：结束标志，用于结束一个TCP会话；
RST(reset)：重置复位标志，用于复位对应的TCP连接。
URG(urgent)：紧急标志，用于保证TCP连接不被中断，并且督促中间层设备尽快处理。
此外，还有两个序号：

Sequence number ：顺序号，发送数据包中的第一个字节的序列号，一般为小写的seq。
Acknowledge number：确认号，响应前面的seq，值为seq+1，可以理解为期望下次发出的序列号为seq+1；

三次握手

四次挥手

（seq和ack一般是延续之前通信的seq和ack）




注意：
1 client第一次发送FIN，只表示不再发送数据，还能接收数据
2 服务器恢复ACK确认了客户端不再发送数据了。要关闭接收通道
3 服务器发送FIN表示不再发送数据了，要关闭发送通道
4 客户端回复ACK确认了服务端要关闭通道，服务端收到客户端确认后立即关闭连接，客户端等待两个MSL后关闭连接，

tcp状态转移

TCP状态转移要点
TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不 会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得 注意的状态有两个：CLOSE_WAIT和TIME_WAIT。

1、LISTENING状态
FTP服务启动后首先处于侦听（LISTENING）状态。

2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。

3、CLOSE_WAIT
对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭

4、TIME_WAIT
我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分 段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情 况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。
目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。

5、SYN_SENT状态
　 　SYN_SENT状态表示请求连接，当你要访问其它的计算机的服务时首先要发个同步信号给该端口，此时状态为SYN_SENT，如果连接成功了就变为 ESTABLISHED，此时SYN_SENT状态非常短暂。但如果发现SYN_SENT非常多且在向不同的机器发出，那你的机器可能中了冲击波或震荡波 之类的病毒了。这类病毒为了感染别的计算机，它就要扫描别的计算机，在扫描的过程中对每个要扫描的计算机都要发出了同步请求，这也是出现许多 SYN_SENT的原因。

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证.

windows 机器设置
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,右键添加名为TcpTimedWaitDelay的
DWORD键,设置为60,以缩短TIME_WAIT的等待时间

ubuntu机器设置

vi /etc/sysctl.conf

编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

查看系统TCP连接资源命令

netstat
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
一般情况下，系统的socket资源默认5000个。（非官方）

TCP协议中有TIME_WAIT这个状态主要有两个原因

1 防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2 可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。

实例：
1 启动socket server端 port：9090

首先netstats会检测到新的listen状态的服务 pid：7932 查看它的fd：

新开了一个文件fd为5的文件监听tcp

2 client端启动 连接端口9090

先通过三次握手简历连接，tcpdump抓取到三次握手，其中Flags[S] 表示SYN，Flags[.]表示ACK

此时netstat也检查到双方已经建立连接，recvq和sendq都为0 表示还没有收发数据

3 客户端发送数据

客户端发送4字节数据

tcpdump到数据包，server接收到数据包 Flags[p] ,表示接收到数据包，并push给上层

netstat也显示内核收到4字节的recv数据

上面是程序还没有调用socket.accept()，内核已经通过tcp建立了连接，将收到的数据先存储起来，等待连接后建立fd(fd是程序内部的)

当程序调用accept，socket会分配给程序java7932，accept相当于将连接包装成socket，之后就只需要调用read()和write()

server端与客户端47513建立连接，接收到了数据

linux内核新开了fd6

总结：

1，tcp是面向连接的，既是还没有分配到对应的program
2 tcp在三次握手之后实际上已经分配到了相应的资源，用于数据交换
3 三个相关命令 lsof -p 查看进程的fd netstat -natp查看网络状态 tcpdump 抓取网络数据

4 socket是内核级的服务，【（客户端ip+port） +（ 服务端ip+port）】四元组构成了一个连接，既是上层不调用accept，也可以有内核完成三次握手和数据的收发

5 socket，fd ，内核buffer之间关系

HTTPS

http工作过程：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5. 释放 TCP连接;
6. 浏览器将该 html 文本并显示内容;

特点：
1 基于 请求-响应 的模式
2 无状态保存，一次请求就是一次新的连接
3 无连接，服务器返回立即断开连接

方法：
GET，POST.PUT,DELETE,UPDATE

TRACE
回显服务器收到的请求，主要用于测试或诊断。

OPTIONS
这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）

request：

response：

OpenSSL

对称加密

简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。

隐患-密钥传输中可能被窃取

非对称加密

简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

1 服务器持有密钥，服务器先将公钥传输给客户端，客户端使用公钥解密后与服务器通讯
2 服务端收到数据够用密钥解密

隐患-公钥可能被窃取，服务端想客户端传送的数据不能保证安全

非对称加密+对称加密

1某网站拥有用于非对称加密的公钥A、私钥A’。
2浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4服务器拿到后用私钥A’解密得到密钥X。
5 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

隐患-第二步的时候黑客劫持数据，将公钥A替换，替换给用伪造的的公钥B发送给客户端，客户端收到公钥B后回复服务端私钥(步骤 3)。黑客劫持数据，用自己的私钥B’解密得到正确的密钥，因此引入CA，保证服务端的身份

数字证书CA

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？

数字签名

数字签名的制作过程：

1CA机构拥有非对称加密的私钥和公钥。
2CA机构对证书明文数据T进行hash。
3对hash后的值用私钥加密，得到数字签名S。
明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

1拿到证书，得到明文T，签名S。
2用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
3用证书里指明的hash算法对明文T进行hash得到T’。
显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

（相当于项目中的sign，header数据+SK通过hash，一起传送，收到后用SK和相同算法加密后对比两个sign）

TLS三次握手

1 TCP三次握手之后，client发送client hello 给server，告诉server支持的TLS的版本以及加密套件，以及第一个随机数random，这里服务端TLS版本为1.2，一共16种加密组合

2 server发送server hello给client，确认支持的版本，生成一个随机数random（第二个随机数），并选择了一种加密套件RSA_WITH_AES_128_GCM_SHA256

3 服务器发送certificate给client出示自己的CA证书，client需要检查证书是否在自己的信任列表

4 server key exchange 服务器发给client公钥

5 server发送 server hello done告诉client发送完毕

6 client发送 client key exchange ，change cipher spec，encrypted handshake message 客户端生成了第三个随机数，这个随机数就是接下来通信使用的密钥，并通过收到的公钥将这个随机数加密发送给server

change cipher spec，就是告诉server以后就用这个约定好的密钥和加密方式通信

encrypted handshake message 就是告诉服务端我这边已经没问题了，协商成功，加密开始

7 服务端回复encrypted handshake message，表示TLS握手成功（第6步服务端收到client加密的第三个随机数后先要密钥解密，得到预主密钥，然后通过第一随机数，第二随机数，和预主密钥通过约定的加密方式计算出会话密钥，client也同样计算出会话密钥，至此完成握手）

总结：

SSL/TLS何时进行

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

RSA算法