- # OSI七层模型
- # TCP/IP网络模型
- # TCP/UDP的区别分别有哪些应用层例子？
- # TCP三次握手
- # TCP四次挥手
- # TCP四次挥手的_第二次_和_第三次_能不能合并,为什么？
- # TCP四次挥手的time_wait简单说下？
- # 聊聊 TCP 的 closing 状态
- # TCP的滑动窗口
- # TCP拥塞控制：拥塞窗口、 慢开始算法、 拥塞避免算法、 快重传、 快恢复
- # 什么是TCP粘包，如何处理？
- # HTTP协议介绍
- # 从浏览器输入网址到页面加载发生了什么？
- # HTTP结构
- # HTTP有哪些返回码，含义？
- # HTTP返回码301/302有啥区别
- # HTTP:默认协议端口，有哪些请求方法？
- # GET和POST区别，文件上传用POST还是GET?
- # 什么情况下出现
connect reset by peer? - # HTTPS: 默认协议端口，请求过程
- # SSL握手的流程
- # 什么是中间人攻击，如何避免中间人攻击
- # Socket的应用场景，如何维持socket链接？
- # 访问外网有墙，墙的原理是什么？在哪个层面上实现的
- # session与cookie的区别，使用场景和方式
- # session的存储
- # 如何防止表单重复提交？
- # 同步IO和异步IO的区别？
- 物理层: 建立、维护、断开物理连接。
- 数据链路层: 建立逻辑连接、进行硬件地址寻址、差错校验等功能。将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。
- 网络层: 进行逻辑地址寻址，实现不同网络之间的路径选择。协议有：ICMP IGMP IP（IPV4 IPV6）。
- 传输层: 定义传输数据的协议端口号，以及流控和差错校验。协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层。
- 会话层: 建立、管理、终止会话。对应主机进程，指本地主机与远程主机正在进行的会话。
- 表示层: 数据的表示、安全、压缩。格式有，JPEG、ASCll、EBCDIC、加密格式等。
- 应用层: 网络服务与最终用户的一个接口。协议有：HTTP、FTP、TFTP、SMTP、SNMP、DNS、TELNET、HTTPS、POP3、DHCP。
TCP/IP模型是一系列网络协议的总称，这些协议的目的，就是使计算机之间可以进行信息交换。
- 连接层：负责建立电路连接，是整个网络的物理基础，典型的协议包括以太网、ADSL等等；
- 网络层：负责分配地址和传送二进制数据，主要协议是IP协议；
- 传输层：负责传送文本数据，主要协议是TCP协议；
- 应用层：负责传送各种最终形态的数据，是直接与用户打交道的层，典型协议是HTTP、FTP等。
- TCP：HTTP、FTP
- UDP：DHCP、DNS
- Client 发送SYN=1的包，指明客户打算连接的服务器的端口，发送序列号为X；Client进入SYN_SENT状态；
- Server 回复确认包(ACK)应答，即SYN和ACK均为1，发送序列号为Y，接受序列号为X+1；Server进入SYN_RCVD状态；
- Client 再次发送确认包(ACK) ，ACK=1，发送序列号为X+1，接受序列号为Y+1；Client和Server进入ESTABLISHED状态；
- Client 发送FIN=1的包，发送序列号为X；停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1状态；
- Server 回复确认包(ACK)应答，即FIN和ACK均为1，发送序列号为Y，接受序列号为X+1；Server 进入CLOSE-WAIT关闭等待状态，此时的TCP处于半关闭状态；Client 收到Server 的确认后，进入FIN-WAIT-2状态；
- Server 数据传输完毕后，发出连接释放包，FIN和ACK均为1，发送序列号为Z，接受序列号为X+1，Server 进入LAST-ACK状态，等待 Client 的最后确认；
- Client 收到 Server 的连接释放包后，对此发出确认包，ACK=1，发送序列号为X+1，接受序列号为Z+1，Client 进入TIME-WAIT状态。此时TCP未释放掉，需要经过时间待计时器设置的时间2MSL后，Client 才进入CLOSE状态；
- 第二次挥手表示收到了关闭连接请求，但是可能还有数据没有传输完成，因此只能先回复ACK；
- 第三次挥手表示数据全部传输完成可以关闭连接；
- 最后一次 Client 的 ACK报文段有可能丢失，使得处于LAST-ACK状态的 Server 收不到对已发送的FIN+ACK报文段的确认，Server 超时重传FIN+ACK报文段，Client 能2MSL时间内收到这个重传的FIN+ACK报文段，接着 Client 重传一次确认，同时重启2MSL计数器，2MSL时间后 Client 和 Server 进入CLOSE状态。
- 防止“已经失效的连接请求报文段”出现在本链接中。Client 在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接的时间内所产生的所有报文段都从网络中消失。这样下一个新的连接中就不会出现这种旧的连接请求报文段。
正常情况下，当发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。表示双方几乎在同时关闭一个连接，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
滑动窗口协议，属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。 该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。 TCP通过滑动窗口的概念来进行流量控制。设想在发送端发送数据的速度很快而接收端接收速度却很慢的情况下，为了保证数据不丢失，显然需要进行流量控制，协调好通信双方的工作节奏。所谓滑动窗口，可以理解成接收端所能提供的缓冲区大小。TCP利用一个滑动的窗口来告诉发送端对它所发送的数据能提供多大的缓冲区。
- 拥塞窗口： 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口；
- 慢开始算法：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小；
- 拥塞避免算法：让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口加1，而不是加倍，让拥塞窗口按线性规律缓慢增长；
- 快重传：要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期；
- 快恢复：当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法；考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞，所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法；
TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。
- 发送方的原因：TCP默认使用Nagle算法，只有上一个分组得到确认，才会发送下一个分组，收集多个小分组，在一个确认到来时一起发送；
- 接收方的原因：TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
- 发送方问题的解决：可以通过关闭Nagle算法来解决；
- 接收方问题的解决：格式化数据、发送长度；
HTTP协议是Hyper Text Transfer Protocol（超文本传输协议），是一个基于TCP/IP通信协议来传递数据的协议，属于应用层的面向对象的协议。
HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
- 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
- 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
- 浏览器发出HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
- 服务器对浏览器请求作出响应，并把对应的响应发送给浏览器;
- 释放 TCP连接;
- 浏览器处理响应;
- Request：请求行、请求头部、空行、请求数据；
- Response：状态行、消息报头、空行和响应正文
- 1xx：指示信息--表示请求已接收，继续处理
- 2xx：成功--表示请求已被成功接收、理解、接受
- 3xx：重定向--要完成请求必须进行更进一步的操作
- 4xx：客户端错误--请求有语法错误或请求无法实现
- 5xx：服务器端错误--服务器未能实现合法的请求
- 301：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI，X今后任何新的请求都应使用新的URI代替；
- 302：临时移动。与301类似。但资源只是临时被移动，客户端应继续使用原有URI；
- 默认80端口；
- GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE 和 CONNECT
- GET：请求的数据会附在URL之后，长度受限，明文传输安全性差；
- POST：把提交的数据放置在是HTTP包的包体中，长度理论上不受限，请求体传输安全性好；
- 文件上传用POST；
- 服务器的并发连接数超过了其承载量，服务器会将其中一些连接关闭；
- 客户关掉了浏览器，而服务器还在给客户端发送数据；
- 浏览器端按了Stop；
- 如果网络连接通过防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个TCP的会话，关闭后在读写，就会导致异常。
基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护。
默认端口443。
- 浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。
- 服务器收到请求，选择浏览器支持的加密算法和哈希算法。
- 服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的。（注释：证书包括以下这些内容：1. 证书序列号。2. 证书过期时间。3. 站点组织名。4. 站点DNS主机名。5. 站点公钥。6. 证书颁发者名。7. 证书签名。因为证书就是要给大家用的，所以不需要加密传输）
- 浏览器进入数字证书认证环节，这一部分是浏览器内置的 TLS 完成的：
- 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。
- 用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。
- 浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密。
- 浏览器将加密的 R 传送给服务器。
- 服务器用自己的私钥解密得到 R。
- 服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器。
- 浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。
- 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；
- 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数；
- 客户端对服务器的证书进行验证(有关验证证书，可以参考数字签名)，并抽取服务器的公用密钥；然后，再产生一个称作pre_master_secret的随机密码串，并使用服务器的公用密钥对其进行加密(参考非对称加/解密)，并将加密后的信息发送给服务器；
- 客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。
- 客户端将所有握手消息的MAC值发送给服务器；
- 服务器将所有握手消息的MAC值发送给客户端。
中间人攻击的前提条件是，没有严格对证书进行校验，或者人为的信任伪造证书。
因此以下场景正是最容易被用户忽视的证书验证环节：
- 网站并没有部署SSL证书，网站处于HTTP明文传输状态。这种情况黑客可直接通过网络抓包的方式，明文获取传输数据
- 黑客通过伪造SSL证书的方式进行攻击，用户安全意识不强选择继续操作。
- 黑客伪造SSL证书，网站/APP只做了部分证书（域名）校验，导致假证书蒙混过关。 **解决方法：**CA 认证体系
- Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。适用于不同进程之间的通信。
- 维持Socket连接的方法：心跳包、KeepAlive保活机制
- 包过滤技术，在网络层、传输层上实现；
- 应用代理技术，在应用层上实现；
- cookie机制采用的是在客户端保持状态的方案，如果不在浏览器中设置过期时间，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称会话cookie。如果在浏览器中设置了cookie的过期时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过期时间结束才消失。cookie是服务器发给客户端的特殊信息，cookie是以文本的方式保存在客户端，每次请求时都带上它；判断用户是否登陆过网站、保存上次登录的时间、上次查看的页面等信息。
- session机制采用的是在服务器端保持状态的方案，当服务器收到请求需要创建session对象时，首先会检查客户端请求中是否包含sessionid。如果有sessionid，服务器将根据该id返回对应session对象。如果客户端请求中没有sessionid，服务器会创建新的session对象，并把sessionid在本次响应中返回给客户端。通常使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。登录信息、不同页面共用的信息等
存储在服务器端的内存中，可以通过特殊的方式做持久化管理。
- 前端：1.禁用按钮提交；2.设置HTTP报头，控制表单缓存，使得所控制的表单不缓存信息；
- 后端：1.幂等判断；2.加锁；
- 同步IO操作：用户进程触发I/O操作并等待或者轮询的去查看I/O操作是否就绪。执行者是IO操作的发起者。需要发起者进行内核态到用户态的数据拷贝过程，所以这里必须阻塞；
- 异步IO操作：用户进程触发I/O操作以后就立即返回，继续开始做自己的事情，而当I/O操作已经完成的时候会得到I/O完成的通知。执行者是内核线程，内核线程将数据从内核态拷贝到用户态，所以这里没阻塞；