SSL操作步骤：
验证服务器端容许顾客端和服务端选择加密算法和密码,确保双方都支持验证顾客端使用私钥加密技术来世成共享加密数据创建一个加密的SSL联接基于该SSL联接传递HTTP恳求
HTTPS的主要作用：一个是构建一个信息安全通道，拿来保证数据传输的安全性，另外一个就是验证网站的真实性了...
HTTP和HTTPS的区别如下:https合同须要ca申请证书，通常免费的证书较少，因此是须要一定费用的]http是超文本传输合同，信息是明文传输，https则是具有安全性的SSL加密传输合同http和https使用的是完全不同的联接方法，用的端口也是不一样的。后者是80端口前者是443端口http的联接很简单，是无状态的；https合同是由SSL+HTTP合同完善的可进行加密传输，身分认证的网路合同，比http合同安全.在OSI模型中，HTTP工作在应用层，而HTTPS工作在传输层
写传输层合同之前先介绍一个四元组的概念:网路通讯的实现就是基于四元组的，不论是TCP还是UDP要想将数据从一端传入到另外一端linux查看网络延迟，就必须明晰对端的二元组,双方若果都要相互通信就要确定四元组
首先我们确定要双方不同主机上的不同进程间进行通讯,必须确定双方的ip+portwhy?
上述图主要是为了引出为何要ip
上述图是为了引出为何须要port
三.TCP合同（三次握手四次挥手细节过程理解在之前的博文中有详尽图解）
报文剖析
源/目的端口，那就是老身常谈了,从那个进程来，到那个进程去
32位序号和确认序号（宽恕咱留个小疑虑红旗linux6.0教程，前面解释，和重传机制有关系）
4位TCP报头宽度:表示该TCP背部有多少个32位bit(有多少个4字节);所以TCP背部最大宽度是15*4=60（基本评判单位都是4字节为最小单位）由于首部宽度是4位最大就是15;所以最大首部宽度就是15*4(最小单位)=60字节
6位标志位:
16位窗口大小（先留个疑，虽然就是储存接收缓冲区还剩下的大小,和流量控制有关）
16位校准和:发送端填充,CRC校准.接收端校准不通过,则觉得数据有问题.此处的检验和不光包含TCP首部,也包含TCP数据部份
6位紧急表针:标示哪部份数据是紧急数据
tcp缓冲区概念的引入(解释流量控制):
tcp联接构建以后是存在接收和发送内核缓冲区的....
send还有recv这种插口都不是直接将数据发送到网络中，也不是直接从网络中读取数据的...
而是存在发送缓冲区和接收缓冲区的概念,这种都是内核缓冲区。。。同样之前的窗口大小或许就是接收缓冲区还剩余的大小,支持流量控制(你发送的数据不能超过，不然就满了)
接收缓冲区小写也对应着流量控制：why？怎样理解
接收端处理数据的速率是有限的.假如发送端发的太快,造成接收端的缓冲区被打满,这个时侯假如发送端继续发送,都会导致丢包,从而导致丢包重传等等一系列连锁反应.
因而TCP支持按照接收端的处理能力,来决定发送端的发送速率.这个机制就称作流量控制(FlowControl)
所以窗口大小就是接收端处理能力的代表(发送端接收到窗口大小会依据窗口大小进行调节自己的发送速率，进行流量控制)填充窗口数组就是填充的自身的接收缓冲区中剩余空间的大小（此窗口称作为接收窗口）
窗口大小数组越大,说明网路的吞吐量越高;
确认应答(ACK)机制的理解（编序号）
ACK应答的含意就是:acknum之前的序号的数据包我都早已收到了,下一次你从acknum开始发送吧
超时重传机制
超时重发指的是由于网路环境的堵车阻塞造成了在很长一段时间发送方都没有等到自己之前发送包的回音（于是TCP默认是丢包）之后会采取重传举措
因为重传机制，会存在一些情况是之前由于网路堵车的数据包在网路环境恢复以后正常传入到对端,造成对端可能会收到多份重复的数据报文，不过嘞由于序号的存在可以通过须要进行简单的去重即可
然而这个超时时间怎样确认???多少算合适，这个也是个置得讨论的问题
最理想的情况下,找到一个最小的时间,保证"确认应答一定能在这个时间内返回".并且这个时间的长短,随着网路环境的不同,是有差别的.假如超时时间设的太长,会影响整体的重传效率;假如超时时间设的太紧,有可能会频繁发送重复的包;
TCP为了保证无论在任何环境下都能比较高性能的通讯,因而会动态估算这个最大超时时间.(抓核心主题，据网路环境而生超时时间)
Linux中(BSDUnix和Windows也是这么),超时以500ms为一个单位进行控制,每次判断超时重发的超时时间都是500ms的整数倍.假如重发一次以后,一直得不到应答,等待2*500ms后再进行重传.假如一直得不到应答,等待4*500ms进行重传.依次类推,以指数方式递增.累计到一定的重传次数,TCP觉得网路或则对端主机出现异常,强制关掉联接.滑动窗口理解
滑动窗口下的丢包问题剖析
第一种是ACK遗失
如上述情况下，滑动窗口的ACK部份遗失虽然不是很紧要，由于可以通过后序的ACK确认；ACK一旦确认以后代表的涵义是默认之前的所有序列数据都早已全部收到了
情况2是数据包传过去的时侯就遗失了
单独解释一下快重传:就是说在接收方收到一个失序的报文段的时侯就立刻会发出重复确认。（目的在于促使发送方尽快地晓得说自己有报文遗失了，没有抵达旁边）接收方地意思就是哥你确定你发的是对的，我后面的报文都还没收到（次序不对呀）三次以后发送方反应过来直接重传，不再等待超时
串扰控制
TCP小结
TCP是面向联接的，可靠的，基于字节流的传输层通讯合同
怎样保证可靠性:
性能提高前面：
1.采取了滑动窗口
2.快速重传(不须要等待超时，三次对端提醒以后手动重传)
基于TCP应用层合同HTTPHTTPSSSHTelnetFTPSMTP
TCP最大联接数的剖析(笔试常考)(从四元组的角度入手)四.UDP合同
先从报文剖析入手
UDP的特点:哪些是无联接，不可靠，关键为何它这么的不稳定并且在现今的短视频音视频通话DNSARP这种全部都还使用的是UDP作为传输层合同
首先是无联接,联接是哪些:联接算是一端到另外一端的不存在的一根线(具象的来说，这个是我的个人理解,联接的过程也就是三次握手的过程)对于三次握手不理解的可以看我前文链接存在解读
首先不论是有联接还是无联接,我们核心应当确定的是哪些?确定四元组，对了四元组，无联接也可以进程间通讯，只不过每一次必须传入四元组,并且口说无凭,咱瞧瞧插口呗。对比一下:
为何UDP是不可靠联接?
由于UDP没有TCP的什么为了保证可靠性的机制:例如超时重传机制linux ftp，串扰控制，流量控制机制，为数据包编号排序等...
思索为何UDP这么不可靠我们还必需要使用它,并且都会尽量的使其显得可靠,还要专门做UDP可靠性设计，这个不是多次一举吗.不如直接使用TCP?
首先解释UDP相比TCP为何相对实时性好,在时间上更短,更推动速。。。
以上是从何必要的三次握手构建联接上解释这个速率问题,为何UDP更快
并且在进行数据传输的时侯TCP就会存在一定的时间限制，时间阀值，超过这个时间就须要进行重传，重传也会造成延后性，向我们的qq聊天呀就常常出现这样的延后现象，很显著底层应该是采取的TCP作为传输层合同.
按照上述的延后解释一下音视频通话为例解释下为何使用UDP而不是TCP？
一句话解释：就是通话延后的问题，我们qq上发个消息是无所谓，延后下我们可以等会看嘛，而且你在跟他人搞音视频，像抖音这种，或则各类视频，这个要是通话延后，几秒前说的话几秒后下来了你这个还搞个屁呀,还说得清嘛，这个很显著须要实时通话linux查看网络延迟，正是这样的场景存在所以UDP必然是须要的。。。并且如今音视频（短视频）这么火热更是少不了UDP了
我们再从另外一个角度来剖析一下这个问题,服务端压力前面来考虑。。。
再谈UDP可靠传输的设计。。。
现有的udp可靠传输合同就是KCP了，感兴趣的还真有必要得去深入研究一下，我个人是研究深度还不够，先姑且通俗的聊一聊这个UDP可靠传输设计的一些基本的东西，KCP要是将来我的理解深入足够会竭力刨析一下...
首先既然提及了MTU先解释一下MTU是个啥玩也.
总结UDP可靠传输的学习:
五.对比TCP和UDP的细节总结本文
