网络TCPUDPHTTPHTTPS一文足矣

　　一、简介
　　TCP、UDP、HTTP、HTTPS都是通信协议，也就是通信时所遵守的规则，只有双方按照这个规则说话，对方才能理解或为之服务。二、TCP、UDP、HTTP、HTTPS之间的关系
　　TCPIP是个协议组，可分为四个层次：网络接口层、网络层、传输层和应用层。
　　在网络层，有IP协议、ICMP协议、ARP协议、RARP协议等。
　　在传输层，有TCP协议与UDP协议。
　　在应用层，有WebSocket、FTP、HTTP、TELNET、SMTP、DNS等协议。
　　而HTTPS可以理解为更安全的HTTP协议。
　　因此，TCP、UDP、HTTP、HTTPS都是通信协议，只不过它们所在的层级不同，负责的工作也不同，并且HTTP是基于TCP实现的。三、Socket通信
　　Socket是为了实现以上的通信过程而建立成来的通信管道，其真实的代表是客户端和服务器端的一个通信进程，双方进程通过Socket进行通信，而通信的规则采用指定的协议。Socket只是一种连接模式，不是协议。TCP、UDP，简单的说（虽然不准确）是两个基本的协议，很多其它协议都是基于这两个协议，如HTTP就是基于TCP的。用Socket可以创建TCP连接，也可以创建UDP连接，这意味着，用Socket可以创建任何协议的连接，因为其它协议都是基于此的。四、TCP协议
　　TCP的建立连接协议又称之为三次握手：
　　第一次握手：建立连接时，客户端发送SYN包（syni）到服务器，并进入SYNSEND状态，等待服务器确认。
　　第二次握手：服务器收到客户端发来的SYN包，必须对客户端进行确认ACK（acki1），同时服务器也发送一个SYN包（synj）到客户端，即服务器会发送SYNACK包，此时服务器进入SYNRECV状态。
　　第三次握手：客户端收到服务器发送的SYNACK包，向服务器发送确认包ACK（ackj1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
　　为什么需要三次握手
　　第一个原因：初始化Seq，TCP通信是有序的，通信双方要通知对方自己的Seq值，也就是上图中的X和Y，这个值要作为之后数据通信的序号，以保证应用层接受到数据不会因网络延时等原因而乱序，TCP会用Seq来拼接数据。
　　第二个原因：在谢希仁版《计算机网络》第四版中讲三次握手的目的是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。在另一部经典的《计算机网络》一书中讲三次握手的目的是为了解决网络中存在延迟的重复分组的问题。这两种不同的表述其实阐明的是同一个问题。
　　谢希仁版《计算机网络》中的例子是这样的，已失效的连接请求报文段的产生在这样一种情况下：Client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后，就误认为是Client再次发出的一个新的连接请求。于是就向Client发出确认报文段，同意建立连接。
　　假设不采用三次握手，那么只要Server发出确认，新的连接就建立了。由于现在Client并没有发出建立连接的请求，因此不会理睬Server的确认，也不会向Server发送数据。但Server却以为新的运输连接已经建立，并一直等待Client发来数据。这样，Server的很多资源就白白浪费掉了。
　　四次挥手过程
　　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，而对方仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。服务器收到这个FIN，发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。服务器关闭客户端的连接，发送一个FIN给客户端。客户段发回ACK报文确认，并将确认序号设置为收到序号加1。
　　为什么需要四次挥手
　　那可能有人会有疑问，在TCP连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢？
　　原因是因为TCP是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。同时发送双方都需要发送FIN报文和ACK报文，加起来就是四次了。
　　TIMEWAIT状态
　　在四次挥手的最后一次挥手中，主动断开方在发送最后一个ACK后，不能立刻关闭，而是需要等待2MSL后才能关闭，这是为什么呢？同时这也是面试中常提到的一个问题。原因如下：
　　假设发起主动关闭的一方（Client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，被动关闭的一方将会重发FIN，在该FIN到达Client之前，Client必须维护这条连接状态，也就说这条TCP连接所对应的资源不能被立即释放或重新分配，直到另一方重发的FIN达到之后，Client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能CLOSED。
　　如果主动关闭一方不维护这样一个TIMEWAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。
　　TCP粘包拆包
　　TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。
　　粘包、拆包发生原因
　　发生TCP粘包或拆包有很多原因，现列出常见的几点：要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
　　粘包、拆包解决办法
　　通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：
　　1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
　　2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
　　3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。
　　那么UDP是否会发生粘包或拆包的现象呢？
　　答案是：不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。五、什么是HTTP协议
　　HTTP全称是HyperTextTransferProtocal，即：超文本传输协议。从1990年开始就在WWW上广泛应用，是现今在WWW上应用最多的协议。HTTP是应用层协议，当你上网浏览网页的时候，浏览器和Web服务器之间就会通过HTTP在Internet上进行数据的发送和接收。HTTP是一个基于请求响应模式的、无状态的协议，即我们通常所说的RequestResponse。
　　先看看请求（Request）报文：
　　请求（Request）报文请求行请求头空行请求体
　　请求行中包含请求方法，常见的请求方法有：
　　GET：获取资源，当前网络请求中，绝大部分使用的是GET方法。
　　POST：传输实体主体，POST主要用来传输数据，而GET主要用来获取资源。
　　PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
　　DELETE：删除文件，与PUT功能相反，并且同样不带验证机制。
　　HEAD：获取报文首部，和GET方法类似，但是不返回报文实体主体部分。主要用于确认URL的有效性以及资源更新的日期时间等
　　响应（Response）报文状态行响应头空行响应体
　　其中，状态行包含响应的状态，常见的状态如下：
　　1XX信息100Continue：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
　　2XX成功200OK204NoContent：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。206PartialContent：表示客户端进行了范围请求，响应报文包含由ContentRange指定范围的实体内容。
　　3XX重定向301MovedPermanently：永久性重定向302Found：临时性重定向303SeeOther：和302有着相同的功能，但是303明确要求客户端应该采用GET方法获取资源。注：虽然HTTP协议规定301、302状态下重定向时不允许把POST方法改成GET方法，但是大多数浏览器都会在301、302和303状态下的重定向把POST方法改成GET方法。304NotModified：如果请求报文首部包含一些条件，例如：IfMatch，IfModifiedSince，IfNoneMatch，IfRange，IfUnmodifiedSince，如果不满足条件，则服务器会返回304状态码。307TemporaryRedirect：临时重定向，与302的含义类似，但是307要求浏览器不会把重定向请求的POST方法改成GET方法。
　　4XX客户端错误400BadRequest：请求报文中存在语法错误。401Unauthorized：该状态码表示发送的请求需要有认证信息（BASIC认证、DIGEST认证）。如果之前已进行过一次请求，则表示用户认证失败。403Forbidden：请求被拒绝。404NotFound
　　5XX服务器错误500InternalServerError：服务器正在执行请求时发生错误。503ServiceUnavailable：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
　　HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：建立TCP连接
　　在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCPIP协议族，因此Internet又被称作是TCPIP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80Web浏览器向Web服务器发送请求命令
　　一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GETsamplehello。jspHTTP1。1。Web浏览器发送请求头信息
　　浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。Web服务器应答
　　客户机向服务器发出请求后，服务器会客户机回送应答，HTTP1。1200OK，应答的第一部分是协议的版本号和应答状态码Web服务器发送应答头信息
　　正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。Web服务器向浏览器发送数据
　　Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以ContentType应答头信息所描述的格式发送用户所请求的实际数据Web服务器关闭TCP连接
　　一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行Connection：keepalive，TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。六、HTTPS的工作原理
　　HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLSSSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLSSSL中使用了非对称加密、对称加密以及HASH算法。握手过程的具体描述如下：浏览器将自己支持的一套加密规则发送给网站。网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。浏览器获得网站证书之后浏览器要做以下工作：
　　a）验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
　　b）如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
　　c）使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。网站接收浏览器发来的数据之后要做以下的操作：
　　a）使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
　　b）使用密码加密一段握手消息，发送给浏览器。浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
　　简单的说：HTTPS使用对称加密的方法通信，秘钥为Key。但是为了安全的把秘钥Key发送给对方，于是在通信前，使用非对称加密的方法加密Key。
　　这样做的目的是：非对称加密的安全性更强，但是加解密过程复杂耗时，对称加密的加解密过程简单，但安全性不强，于是HTTPS综合两种加密方式，既保证了安全性，又保证了效率。
　　HTTPS协议和HTTP协议的区别：HTTPS协议需要到ca申请证书，一般免费证书很少，需要交费。HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。HTTP和HTTPS使用的是完全不同的连接方式用的端口也不一样，前者是80，后者是443。HTTP的连接很简单，是无状态的。HTTPS协议是由SSLHTTP协议构建的可进行加密传输、身份认证的网络协议，要比HTTP协议安全。
　　文章来源：小道萧兮https：www。jianshu。comp8153b6d3a3e8