Java—TCP与HTTP连接

输入一个url到浏览器页面展示过程：

1. 输入网址
2. 缓存解析
3. 域名解析
4. tcp连接，三次握手
5. 服务器处理请求并返回报文
6. tcp断开连接，4次挥手
7. 页面渲染

TCP传输控制协议/UDP用户数据报协议：

• TCP面向连接、字节流、全双工的可靠信道，发送端时经过各层时都要附加上相应层的协议头和协议尾（仅数据链路层需要封装协议尾）部分，与原数据大小不同。
• UDP无连接、报文流、不可靠信道，发送时与原数据大小相同。
• 接收缓冲区被TCP和UDP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，buffer满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。
• UDP：当套接口接收缓冲区满时，新来的数据报无法进入接收缓冲区，此数据报就被丢弃。UDP是没有流量控制的;快的发送者可以很容易地就淹没慢的接收者，导致接收方的UDP丢弃数据报。

流量控制：

TCP中采用滑动窗口来进行流量控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报。

拥塞控制：

拥塞窗口指某一源端数据流在一个RTT内可以最多发送的数据包数。

防止发送方发的太快，使得网络来不及处理，从而导致网络拥塞

• 慢启动： 网络传输刚开始时，并不知道网络的实际情况，所以采取一种试探的方式控制数据的发送速率。慢启动阶段，数据的发送速率以指数方式增长，即就是拥塞窗口的增长，每次都是收到确认报文段数量的2倍。可以看出慢启动并不慢，拥塞窗口增长的速度很快。所以，为其设置了一个慢启动门限，当达到门限时，就进入到拥塞避免阶段。
• 拥塞避免： 当拥塞窗口的大小采用慢启动方式增长到慢启动门限时，就进入拥塞避免阶段，拥塞避免阶段不再以指数形式增长拥塞窗口，而是每经过一个往返时间RTT就将发送方的拥塞窗口+1， 使其增长速度减缓。按照线性方式增长。如果发生网络拥塞，比如丢包时，就将慢启动门限设为原来的一半，然后将拥塞窗口设置为1，开始执行慢启动算法。（较低的起点，指数级增长）。
• 快速重传： 假设发送方发送的报文段分别为： M1,M2,M3,M4,M5,M6 , 当接收方收到M1和M2后，M3报文段丢失，接着收到的M4，M5，M6都不做处理，而是没接收到一个报文段就对M2重复确认，发送方接收到重复的三次确认报文段，就对其后的报文段进行重新发送，而不需要等待超时时间到达。当快速重传后，立即进入到快速恢复阶段。
• 快速恢复：将慢启动门限设置为原来的一半，然后将拥塞窗口设置为现在的慢启动门限值，不再执行慢启动算法，而是直接进入拥塞避免阶段。使发送窗口成线性方式增大。

TCP连接：

• ACK：确认序号有效。
• SYN：发起一个新连接。
• FIN：释放一个连接。

握手(挥手)过程中必须有SYN(FIN)与ACK在同一次握手(挥手)当中传输，意味着确定打开(关闭)连接了。

TCP的三次握手：

• ack = 另一端发送的seq + 1
• seq = 另一端发送的ack
• 另一端没有发送则建新值

第三次握手原因：

防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

TCP的四次挥手：

挥手需要四次原因：

第二次只发送ACK，但是还不能发送FIN，因为服务端还有数据没发完，所以在CLOSE-WAIT阶段等待剩余数据的发送，发送完数据则发送ACK+FIN跟客户端确定可以关闭连接了，进入LAST-ACK阶段等待最后一次确定状态，客户端再发送一次ACK确定收到关闭连接消息，服务端就进入CLOSED。

客户端在TIME-WAIT等待2MSL原因：

MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

防止服务端没有收到最后一次ACK，因为服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文。

HTTP协议：

1.请求报文

• 请求行                    请求方法(Method)、URL字段和HTTP协议版本
• 请求头                    存放对客户端想给服务端的附加信息
• 请求体                    真正需要发给服务端的数据

2.响应报文

1. 响应状态行             状态行是服务端返回给客户端的状态信息，包含HTTP版本号、状态码、状态码对应的英文名称。
2. 响应头与响应实体

• HTTP是基于TCP的，客户端往服务端发送一个HTTP请求时第一步就是要建立与服务端的TCP连接，也就是先三次握手
• socket层只是在TCP/UDP传输层上做的一个抽象接口层，因此一个socket连接可以基于TCP连接，也有可能基于UDP。
• HTTP采用“请求-响应”机制，在客户端还没发送消息给服务端前，服务端无法推送消息给客户端。必须满足客户端发送消息在前，服务端回复在后。Socket连接双方类似peer2peer的关系，一方随时可以向另一方喊话。

get和post的区别

功能不同：

• get是从服务器上获取数据。
• post是向服务器传送数据。 

过程不同：

• 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
• 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

传送数据量不同

• get传送的数据量较小，不能大于2KB。
• post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 

安全性不同

• get安全性非常低。
• post安全性较高。 

对称加密

• 客户端和服务器共用同一个密钥，该密钥同时用于加密和解密一段内容。
• 对称加密的优点是加解密效率高，但是在安全性方面可能存在一些问题，因为密钥存放在客户端有被窃取的风险。对称加密的代表算法有：AES、DES等。

非对称加密

• 将密钥分成了两种：公钥和私钥。
• 公钥通常存放在客户端，私钥通常存放在服务器。
• 使用公钥加密的数据只有用私钥才能解密，反过来使用私钥加密的数据也只有用公钥才能解密。
• 非对称加密的优点是安全性更高，因为客户端发送给服务器的加密信息只有用服务器的私钥才能解密，因此不用担心被别人破解，但缺点是加解密的效率相比于对称加密要差很多。非对称加密的代表算法有：RSA、ElGamal等。

HTTP无状态：

无状态是指，当浏览器给服务器发送请求的时候，服务器响应客户端请求。

但是当同一个浏览器再次发送请求给服务器的时候，服务器并不知道他就是刚才的那个浏览器。

简单的说，就是服务器不会去记得你，所以就是http的无状态协议。

保存用户状态的两大机制：

HTTP与HTTPS：

• HTTP+SSL(Secure Sockets Layer 安全套接字协议),
• 传统的http方式传输数据时信息都是明文的，数据很容易被监听和窃取。传输的数据还有可能被一些别有用心的人篡改，导致浏览器与网站收发的内容不一致。
• HTTPS采用对称加密+非对称加密的方式

SSL协议的握手过程

1. 客户端 给出协议版本号，加密算法，随机数A
2. 服务端 给出协议版本号，加密算法，随机数B，公钥证书
3. 客户端 校验服务端公钥证书，发送客户端公钥证书给到服务的
4. 服务端 校验客户端公钥证书，服务端发送客户端公钥加密的加密方式给客户端，相互确认加密方式
5. 客户端 生成随机数C，用确定好的加密方式将3个随机数生成对称密钥，用以加密后面的通讯。将该密钥用服务端公钥加密后发过去。
6. 服务端 解出公共密钥

浏览HTTPS网站过程：

浏览器随机生成密钥，然后用CA机构发的公钥加密一层，传输到网站后，网站获得密钥。网站收到了浏览器随机生成的密钥之后，双方就可以都使用对称加密来进行通信了。

浏览器获取网站的公钥，以及保证公钥的安全性由CA机构保证。

• CA机构则会使用网站管理员提交的公钥，再加上一系列其他的信息，如网站域名、有效时长等，制作证书。
• 有浏览器请求网站时，首先会将这段加密数据返回给浏览器，此时浏览器会用CA机构的公钥来对这段数据解密。
• 如果能解密成功，就可以得到CA机构给我们网站颁发的证书了，其中包括了网站的公钥。

单向认证、双向认证

单向认证指的是只有一个对象校验对端的证书合法性。通常都是client来校验服务器的合法性。那么client需要一个ca.crt,服器需要server.crt,server.key
双向认证指的是相互校验，服务器需要校验每个client,client也需要校验服务器。server 需要 server.key 、server.crt 、ca.crt。client 需要 client.key 、client.crt 、ca.crt。