自己的笔记，自己才看的懂，很多图片我都没有说明，见谅
TCP/IP参考模型
说说TCP的三次握手
IP协议是无连接协议，他不会占用两个正在通信计算机的通信线路，这样IP就降低了对网络线路的需求，每条线可以同时满足不同计算机之间的通信需要。通过IP消息会被分割成较小的比较独立的包，并通过因特网在计算机之前传送，IP负责将每个包路由至他的目的地。IP协议没有做任何事情来确认数据包是否按顺序发送，或者包是否被破坏，所以IP数据包是不可靠的。需要由他的上层协议 来做成控制。
TCP是 面向连接的，可靠地，基于字节流的传输层协议。TCP将应用层的数据流分割成报文段，TPCP为了不丢失包，每个数据包都有序号，即Sequence Number,序号也保证了传送到目标节点的包的按序处理，然后接收方实体对已经接受到的包发送一个相应的确认，即ACK确认，如果发送端实体是合理的往返时间内即RTT内未收到确认，那么对应的数据包就会假设为已丢失，并且将会对器进行 重传。TCP用一个奇偶校验和函数来检验数据是否有错误，在发送和接受的时候都要计算校验和。
所以TCP的三次握手是为了在两台计算机之间建立一条全双工通道的连接，将会占用两个计算机之间的通信线路。直到他被一方或者双方关闭为止。
为什么需要三次握手才能建立起来连接呢？
网上那些什么你答我答都是说给外行人听得！！
主要是为了初始化Sequence Number的初始值，通信的双方要互相通知对方自己的初始化的Sequence Number，也就是上图中的X和Y，这个号要作为以后的数据通信的号以保证应用层接收到的数据不会因为网络上的传输问题而乱序，即TCP会用这个序号来拼接数据，因此在服务器回发他的Sequence Number即第二次握手之后，客户端还需要发送确认报文给服务器，告诉服务器客户端已经收到你的Sequence Number了，此外在第一次握手的时候，有一个隐患，即SYN的超时问题，服务端收到客户端的SYN,回复SYN-ACK的时候，客户端掉线了服务端未收到ACK确认，那么这个链接就会处于一个中间状态，即没有成功也没有失败，于是服务端在一定时间内没有收到客户端的回执，就会重发SYN(Sing)-ACK,在Linux下，默认重试5次每次重试时间从一秒开始翻倍（总工室63秒）。这样可能就导致服务器受到SYN-Flood的攻击 风险，恶意程序呢会给服务器发一个SYN的报文，发了之后呢他就下线了，于是服务器会默认等63秒，才会断开这个链接，这样攻击者就会把服务器的SYN这个呢的连接队列耗尽，让正常的连接请求不能处理，于是呢在Linux下，就有一个tcp_syncookies来应对这个事情，当SYN队列满了之后，TCP会通过源地址端口目标地址端口，和时间戳打造出一个特别的Sequence（SYN Cookie）回发回去，如果是攻击者，他是不会有响应的，如果是正常连接，则会把这和个Cookie发回来，然后服务端可以通过Cookie建立连接，通过SYN Cookie即使我们的SYN队列满了。本次连接请求不在队列中，依然能够建立连接，所以就解决了这个问题。
如果建立了连接，客户端依然发生了故障怎么办？
TCP有一个保活机制，在保活时间内，连接处于非活动状态，服务端向客户端发送保活探测报文，未收到响应继续发送，直到尝试次数达到保活探测次数则会中断连接。
TCP的四次挥手
挥手是为了终止连接。在Socket编程中，有客户端或者服务端执行close来触发。
1.为什么最后客户端还有一个Time Wait状态，为了确保有足够的时间对方收到ACK包，如果被动关闭的一方没有收到ACK包，那么被动关闭的一方就会重发FIN包，一来一去正好是两个MSL。
2.有足够的时间让这个连接不会跟后面的连接混在一起。
为什么需要4次挥手才能断开连接
因为全双工通道的关系，发送方和接收方都需要FIN报文和ACK报文，也就是说发送方和接收方各自需要两次挥手即可，只不过有一方是被动的，看上去就是所谓的四次挥手。
服务器出现大量close_wait状态的原因
遇到这种情况多数是，程序的BUG，连接没有及时释放导致的。
或者是线程池中的线程数字没有配置合理。
UDP简介
1.UDP是一个非连接的协议，传输数据之前源端和终端无简历连接，当他想传送时候，就简单的抓取来自应用程序的数据，并尽可能快的把它扔到网络上，在发送端，UDP传送数据的速度，仅仅是受应用程序生成数据的速度，计算机的能力和传输带宽的限制，在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读取一个消息段
2.UDP不建立连接，因此不维护连接状态，支持用时向多个客户端传输相同的消息。
3.UDP的数据包头只有8个字节，相较于TCP的20个字节信息 ，额外开销小很多。
4.吞吐量不受拥塞控制算法的控制。
5.尽最大努力交付，不保证可靠交付，不需要维持复杂的的链接状态表。
6.面向报文的，不对应用程序提交的报文信息进行拆分或者合并。
TCP和UDP的区别
他们两个都是OSI模型中运输层的协议，TCP提供可靠的通信传输，而UDP而常用于广播和让细节控制交给应层的通信传输
TCP是可靠地，利用握手确认和重传机制提供了可靠性保证，UDP可能会丢失。
TCP利用序列号的保证了消息报的顺序交付，达到可能无序，但是最后hi排序。
TCP的速度慢比UDP慢，因为TCP在 保证可靠性和有序性方面做了更多的工作。
UDP适用于对速度敏感的应用，在线视频媒体，电视广播，多人在线游戏。
数据开销大小
HTTP
他是应用层的协议，他是一个基于请求与 响应模式无状态的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种 持续连接的机制 Keep Alive ,绝大多数WEB开发都是基于HTTP协议之上的WEB应用，他的主要特点有：
1**.支持 客户、服务器模式** HTTP协议工作与客户端服务端架构之上，浏览器作为HTTP客户端通过URL向HTTP服务端发送请求，服务器服务器根据接收到的请求向WEB服务器发送响应信息。
2**.简单快速** 客户端向服务器请求服务的时候，只需要传送请求方法（get/post）和路径。
3.灵活 HTTP允许传输任意类型的数据类型，
- 无连接 限制每一次连接值处理一个请求，服务器处理完客户的请求并收到客户的应答之后即断开连接。在HTTP 1.1之后默认采用长连接，就是服务器需要等待一段时间后才断开连接，以保证连接特性。
- 无状态 协议对于事务处理没有记忆能力，缺少状态意味着如果后续处理需要传的信息必须被重传，这样可能导致 每次连接穿的数据量增大，另一方面，在服务器不需要先前信息时，他的应答就较快。
HTTP协议定义了WEB客户端如何从WEB服务器请求WEB页面，以及服务器如何吧WEB页面传送给客户端，HTTP协议采用了请求响应模型，客户端向服务器发送一个请求报文，请求报文包含一个请求的方法，URL,协议版本，请求头部和请求数据，服务器以一个状态行作为 响应，响应的内容包括协议的版本，成功或者错误的代码， 服务器信息，响应信息，和响应数据。
以下是HTTP响应的步骤：
1.客户端连接到服务器，建立一个TCP套接字连接，
2.发送HTTP请求，通过TCP套接字，客户端向服务器发送一个文本的请求报文，
3.服务器接收请求并返回一个HTTP响应，WEB服务器接收请求，定位请求资源，服务器将资源副本 写到TCP套接字由客户端读取，
4.释放TCP连接。
5.客户端拿到相关的HTML内容并进行解析，首先解析状态行，查看表明请求是否成功的状态代码，然后解析每一个响应头，响应头告知以下是需要解析的HTML文档。然后解析HTML
在浏览器输入URL，按下回车后发生了什么
1.DNS解析：首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL的域名所对应的IP地址。
2.找到IP地址之后会根据IP地址和对应端口和服务器建立TCP连接，这里就涉及到了3次握手。
3.然后浏览器会发出 读取文件的HTTP请求，该请求发给服务器
4.服务器对浏览器请求作出相响应，并把对应的带有HTML文本的HTTP响应报文回浏览器
5.浏览器接收到响应报文，假设本次请求是成功的，就会解析HTML文档在浏览器上渲染HTML页面。
6.浏览器释放TCP连接，涉及到了4次挥手
说说常见的HTTP状态码
状态码由三位数组成的，第一位定义了相应的类别
1XX:表示请求已经接受，正在处理
2XX:表示请求成功 接受，理解，接收。
3Xx:重定向 表示 你要完成请求需要完成进一步的操作
4XX:客户端错误，请求有语法错误，或者请求无法实现
5XX：服务端错误 服务端未能实现合法的请求
GET 和POST区别
HTTP报文层面：GET请求将请求信息凡能够在URL，信息以键值对的样式在链接中存在，而POST请求信息放在报文体中，要获取请求信息必须解析报文。安全性比Get高，其实要解析POST请求也是非常简单的，所以要解决安全问题还是要依靠HTTPS。（抓包就行了）Get请求信息有长度限制，post没有限制。
数据库层面：Get请求符合幂等性和安全性，POST不符合。
对数据库的一次操作和多次操作获得的结果是一致的，安全性是指是对数据库的操作 没有改变数据库的数据 。
Get一般 用作查询，一般是符合幂等性和安全性的
POST请求会往数据库中提交数据，因此会改变数据库中的数据，其次POST请求的每次获得的结果都有可能不一样。因为POST请求是作用在上一级的URL上的，则每一次请求都会添加新资源。
Get可以被缓存，POST请求不能：Get请求可以被浏览器缓存，可以被浏览器保存为浏览器书签，POST方式不具备。
Cookie 和Session的区别
因为HTTP数无状态的，因此我们每次访问有登录需求的时候，都要不厌其烦的输入账号密码，然而实际上却没有出现这样的情况，这是因为引入了Cookie 和Session使HTTP具备了状态。
Cookie：是服务器发给客户端的特殊信息，以文本的形式存在客户端，客户端每次向服务器发送请求的时候，都会带上这些信息。也就是说当用户使用浏览器访问支持Cookie的网站的时候，用户会提供个人信息，并且提交至服务器，紧接着服务器宰相客户端回传超文本的同时也会发回这些个人信息，这些信息并不是存在HTTP Response Body，而是在HTTP Response Head。当浏览器接收到这样的信息的时候，浏览器会将这些信息存放在统一的位置，之后，再向服务端发送需要个人信息的时候，会将这些信息携带至请求头中，服务器接收到再收到带有Cookie的信息，会解析Cookie然后做其他操作作出响应。
Session:是服务器端的机制，服务器使用一种类似散列表的结构来保存信息，当程序需要为某个客户端请求创建一个Session的时候，服务器首先检查这个客户端的请求里是否已经包含了一个Session标识,也就是Session ID,如果包含了Session ID,则说明以前已经为这个客户端创建了Session,服务器就按照Session 吧Session检索出来使用，如果检索没有，就新建一个。如果请求没有Session ID,则为此客户端创建一个Session,并生成一个于此相关的Session ID,这是一个不会重复也没有 规律的字符串， 这个Session ID会在响应中回发给客户端并保存。
Session的实现方式：
使用Cookie实现，服务器回发一个JSESSIONID给客户端，客户端时候到保存下来请求的时候在带上。
使用URL回写实现：URL是指服务器在发送给浏览器页面的所有链接中， 都携带JSESSIONID 的参数，这样客户端店家让后人的连接都会携带上这个。
区别：
一个在客户端，一个在服务端。
Cookie不安全，别人可以分析存在本地的Cookie.
如果考虑减轻服务器负担，应当使用Cookie
HTTP HTTPS的区别
SSL（Security Sockets Layer）安全套接层
为网络通信提供安全及数据完整性的一种协议
SSL位于TCP与各应用层之间，是操作系统对外的API，SSL之后改名TLS.
采用身份认证和数据加密来保证安全。
**HTTPS数据传输流层*程：
浏览器将支持的加密算法信息方给服务器，
服务器选择浏览器支持的加密方式以证书的形式回发浏览器，
浏览器验证证书的合法性，并结合证书公钥加密信息发送给服务器，
服务器收到信息，利用私钥解密信息 ，加密响应信息回发浏览器。
浏览器解密响应信息，并且对消息进行验证，之后进行加密交互数据。
区别：
HTTPS需要到CA申请证书，HTTP不需要。
HTTP是密文传输，HTTP是明文传输
HTTPS默认使用443端口，HTTP默认是80端口。
浏览器默认填充HTTP，网站采用301或者302跳转到HTTPS，这个过程使用了HTTP，还是会受到劫持。
可以使用HSTS优化。
