话说上回说到我和其他朋友们讨论来讨论去总算是大致解决了任意两台计算机之间的通信问题，不过又有新问题了：
“（我）诸位，我发现上次咱们是依据OSI模型讨论问题的，但这个模型其实并不是那么合适，有一些冗余之处。大家想一想，会话层和表示层实际上都是与应用程序配合工作的，而物理层那些纯硬件层面的问题其实并不是我们的领域，我们最多只要处理到与硬件的接口这一层次上就足够了。”“的确啊。”“（我）工作室需要合并一下：物理层与数据链路层合并为网络接口层，只负责硬件接口相关任务，硬件问题就不要去管它了；网络层改名为网络互连层，更为清晰；传输层不变；会话层，表示层和应用层合并为一层，统称应用层。”
现在实际使用的就是TCP/IP模型，也称作TCP/IP协议栈，由以下4层组成（这些层都不是真实存在的，只是一种抽象概念而已）：
1，网络接口层
一般认为对应OSI模型中的物理层和数据链路层，但实际上TCP/IP标准并不定义与OSI数据链路层和物理层相对应的功能。相反，它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议，提供TCP/IP协议的数据结构和实际物理硬件之间的接口，例如PC的网卡驱动程序。
2，网络互连层
一般认为对应OSI模型中的网络层，包含IP协议、RIP协议(Routing Information Protocol，路由信息协议)，负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。注意，ICMP其实位于IP层之上，但它却是IP的附属协议，在OSI模型和TCP/IP协议栈中都没法放在一个合适的位置上。没办法，没有哪个模型是完美的。
3，传输层
一般认为对应OSI模型中的传输层，能够解决诸如端到端可靠性（“数据是否已经到达目的地？”）和保证数据按照正确的顺序到达这样的问题，也包括所给数据应该送给哪个应用程序。
4，应用层
一般认为对应OSI模型的会话层，表示层和应用层，该层包括所有和应用程序协同工作，利用基础网络交换应用程序专用的数据的协议。应用层的协议是要依赖传输层的协议工作的，应用层协议运行在传输层的TCP或UDP协议之上（这句话的意思是应用层协议负责打包封装数据提供给客户端或服务器端有用信息，再由传输层协议接过封包进行处理和传输）。
“（我）诸位，任务来了：A地的PC用户想要浏览网页，对应的网站服务器在半个地球之外的B地呢。开始吧！”"我先处理用户的请求！（HTTP和其他几位（其中有原来的表示层工作室成员））"“我们一起建立可靠连接！（TCP和IP异口同声。PS：TCP和IP总是配合工作，TCP的查错机制中就有一步是对整个TCP段和伪段头（IP头的一部分）检查和，有些用户参数TCP直接传递给IP层处理），应用层的诸位，数据封装好之后就交给我们来处理传输！”“YES！（应用层）”“然后我们就可以把这些逻辑信息最终转化为物理信息送出去了！（网络接口层的诸位）”“（我）似乎还漏了负责路由器的几位......算了，他们太低调了，有空再介绍吧。”
“咳咳，这样传输的可是明文啊，你们不在乎数据被窃听复制篡改或者落到中间人的手里？”
“（我和其他人）SSL？什么中间人？”
“叫我TLS！算了，这不重要，你们想象一下这样的场景：一个不怀好意的第三方想要窃取用户数据，那么他会在路上伪装成目标网站服务器接收数据......”
“（我）第三方无法满足用户请求的，而且有独一无二的域名做保证......”
“笨蛋！域名系统是很不可靠的，域名欺骗域名劫持域名污染这些都是常有的事！[3]还有，第三方完全可以先截取用户数据，再自己当客户端与目标网站建立连接，从目标网站抓取数据之后再转交给用户，这样用户就根本无法察觉自己被中间人攻击了！”
"（我）那你说该怎么办？（生气中）"
“首先，用户数据当然要被从头到尾都被加密了，而且要是强加密，否则分分钟被暴力破解；然后，需要有一个可靠的身份验证机制，保证用户和服务器之间没有第三方；还有，必须要保证一个数据包都不掉队，要知道为了建立加密连接我可是要帮客户端和目标服务器握手呢，这期间要是有数据包丢了而我却不知道，那就搞笑了！所以我要在TCP的帮助下工作（TCP：OK，建立可靠连接，我最擅长了！）最后就是，客户端和目标服务器各自持有不能被第三方截取到的密钥，要不然加密就失去意义了。”
“（我）那么，双方事先准备一对密钥？”
“不现实。鬼才知道用户想要和哪些网站建立HTTPS连接，怎么个事先准备法？又该用什么途径把密钥送到用户手里？网站服务器要是一直都用一个密钥，那么在不知情的情况下被第三方偷走了怎么办？那样后果会相当严重的！必须做到每个连接两个独一无二的密钥！”
“（我）等一下，两个？两个不同的密钥？”
“没错。如果是相同的密钥（采用对称加密，例如你用7zip加密了压缩包，密码设置为123456，那下次打开压缩包解密时也是输入123456，加密密钥和解密密钥是同一个），那么怎么秘密传递密钥就又是一个无解的问题了。你总不能线下交给用户吧（笑），如果加密传递，那么就变成一个先有鸡还是先有蛋的问题了：加密传递时的解密密钥又该如何安全传送？那么只能采用非对称加密了，加密密钥（公钥）是明文传递的，解密密钥（私钥）是秘密的，这样第三方只能干瞪眼。不过如果第三方伪装成目标服务器，那么他还是有办法对付非对称加密的，所以还需要可靠的身份验证机制。”
“（我）那么你的想法具体是怎样的呢？”
“说来话长，我的想法并不是那么容易理解的，下次再具体说明吧。”
“（我）好吧，TLS，下次就是你的专场了（笑）。对了，你有一个缺点，介意我提出来吗？”
“说吧，幽灵。”
“（我）拜托你能不能改掉这个不打招呼就冷不丁插话的坏毛病！（咆哮）”