前言
其实本文仅仅是解说从传输层到应用层实现网络消息传递的一个具体流程，至于更底层的网络层和网络接口层，那就不在我的考虑范围内了，其实那部分机制是不须要你去担心的，除非你想开发操作系统！
然后本文打着通俗易懂的标题，所以在前言之后我将不会提及不论什么一个新手可能会不理解的keyword或专业术语（也就是说这样仅仅是方便了理解并不方便使用。但这就是本文的目的。毕竟有了清晰的理解之后不管再换到哪个平台都是相同的使用方式，仅仅只是部分专业术语我可能会在它第一次出现的位置放个【】描写叙述一下它的本名），接下来我将开启典型的情景模式进行解说。
首先声明，本文主要是依据自己的理解编写而来。假设有错误的地方。不要犹豫，直接打脸即可了。
背景
电脑A和电脑B【server和client】是相隔了未知距离的两台电脑。有一天，A突然想要跟B打招呼（或许是冥冥之中的命运。他知道了B的存在）。这时互联网大哥就出来了（至于这货是怎么诞生的有兴趣的再去查他的生辰吧），A和B都买了一根最新潮的网线【数据传输线】，插在自己身上同一时候两人都连接到了互联网内。
互联网大哥这时就開始推销了：你想要跟B打招呼吗？拜托我不就成了。A你把要说的话告诉我，然后我再告诉B。同一时候B要对你说的话我也能反馈给你。
A一听兴奋了。原来打个招呼这么简单。想着他一股脑儿的把自己想说的话通通告诉了互联网大哥，然后......
就没有然后了。互联网大哥跑断了腿也没能找到B住在哪儿，由于A并没有告诉他B的住处，其实A也不知道B的住处，所以。这场原本预料之中无比轻松欢快的交流宣告破裂。
【随意电脑连接至互联网。便能够通过互联网数据传输，电脑间的资源共享其实就是把一台电脑的资源数据通过互联网传递到还有一台电脑。在还有一台电脑生成一个一模一样的资源，从而实现了资源共享】
问题来了：怎么找到B的住处？
这天，A在医院陪着断腿的互联网大哥，他们商议着一种能够找到B的住处的方法。
互联网大哥：我们整个互联网家族兄弟姐妹千千万万，B尽管也是托付给了我们家。但我也找不到跟他直接联系的那个人是谁呀，有可能是我千千万万兄弟姐们姨嫂舅伯中的不论什么一个。
A点着头：对。这确实是个麻烦事。看来我们的首要目的就是要先知道B的住处。
想了一想，这时互联网大哥突然一拍脑门：我想到法子了，我让族里的兄弟姐妹们给每家每户都标个门牌号【IP地址】不就得了。这种话往后家家户户串门就要easy得多了。
想着，互联网大哥直接从病床上翘了起来。不顾A的拦阻瘸着个断腿就跑出了医院，他迫不及待的想要把这种新潮的想法普及给族里的每一个兄弟姐妹，这种话。他也能帮助A找到B的住处了。
......
也不知道是过了多久以后。这天互联网大哥再次登门到了A家。
A无比热情的迎接了他。饭后互联网大哥递了一张名片给A：这是B家的门牌号。
A接过这张名片，听着互联网大哥给他介绍上面的基本信息：147.258.369.145是他家的门牌号。如今注冊门牌号的住户太多，我们分了四个0到255的数再通过符号点连接组成，至于为什么要用点来连接，嘿嘿，这也是我提的方式。毕竟147.258.369.145比147258369145easy识别得多。
听着互联网大哥说完。A算是明确了：那这么说的话往后我把想说的话告诉你，你就能通过这个门牌号传达到B那里去了吗？
互联网大哥点着头：对，并且不仅仅是我，仅仅要是我们家族内的不论什么一个成员，你把要传递的话告诉他，再把传递的门牌号告诉他，他都能帮你传达消息。
A一听兴奋了，原来打个招呼最终变得这么简单了，想着他一股脑儿的把自己想说的话通通告诉了互联网大哥，然后......
就没有然后了，互联网大哥跑断了腿也没能找到哪个是B。由于B的家族里也有数不清的兄弟姐妹，非常明显他也不知道当中哪个是B。所以，这场原本预料之中无比轻松欢快的交流重新宣告破裂。
【互联网中通过IP地址 + port号才干完整的定位到某台电脑的某个程序。从而向该程序发送数据，仅仅依靠IP地址的话不能发送到特定的程序】
问题来了：怎么知道在B的家族中哪个是B？
这天。A陪在医院替互联网大哥削着苹果。
互联网大哥想来想去总认为这刚施行起来的门牌号机制还是不太完善，只是突然他灵光一闪，又想到了一个极好的法子来改善这个门牌号机制：对呀。我们要是给每家每户的每口人都制定一个身份证【port号】不就得了，这样通过门牌号和身份证就能够准确的找到B了。
想着。互联网大哥直接从病床上翘了起来。不顾A的拦阻瘸着个断腿就跑出了医院。他迫不及待的想要把这种更新潮的想法普及给族里的每一个兄弟姐妹，这种话，他也能帮助A找到B了。
......
也不知道是过了多久以后，这天互联网大哥再次登门到了A家。
A无比热情的迎接了他，饭后互联网大哥递了一张名片给A：这是B家的门牌号和B的身份证。
A接过这张名片，仅仅见上面写着：147.258.369.145:80。后面这个80的话应该就是B的身份证了。
A说：这种话往后我把想说的话告诉你，你就能通过这个门牌号和身份证传达到B那里去了吗？
互联网大哥点点头：对。
A一听兴奋了，原来打个招呼最终变得这么简单了。想着他一股脑儿的把自己想说的话通通告诉了互联网大哥。然后......
就没有然后了。互联网大哥尽管把A说的话带到了B那里，但B全然看不明确A在说些什么。由于互联网大哥是用录音机【编码】来记录A的传话的，而他们的录音机仅仅能记录一些正常人全然没法看懂的由数字1和数字0组成的数据【二进制数组】，所以。即便他将A说的话完善无损的用录音机录了下来。但到了B那里时却不知道用什么方式才干播放出来了，所以，这场原本预料之中无比轻松欢快的交流重新宣告破裂。
【互联网中传递的数据都是由1和0组成的字节数组，随意数据类型（int、string等）。随意文件（.mp4、.mp3等）都能转换为字节数组从而在网络中传递。接收方依照传输方的编码方式对字节数组进行转换之后，得到特定的数据类型或文件，这才算是完毕了数据的传输】
问题来了：A要传递的话已经到了B的手里。但怎么才干让B看懂A所说的话呢？
这天，A又和互联网大哥聚在一起。
互联网大哥抱怨说：一定是录音机有问题，我要去找生产厂商投诉。
A提议道：找厂商定做一款播放器不就得了。能够把录音机录下来的声音原封不动的回放出来。
听A这一说，互联网大哥一拍脑门：好主意啊，这种话我们也不用管录音机里装的那些1啊0的是些什么数据了，仅仅管让播放器依照录音机录音的方式【编码方式】进行回放就能够了！
想着。互联网大哥立刻就跟A道别离去，也不顾A的挽留，他迫不及待的想要把这种更新潮的想法普及给族里的每一个兄弟姐妹，这种话，他也能帮助B听到A的传话了。
......
也不知道是过了多久以后，这天互联网大哥再次登门到了A家。
A无比热情的迎接了他，饭后互联网大哥介绍了他们最新的传话工具，录音机和播放器。
A一听兴奋了，原来打个招呼最终变得这么简单了，想着他一股脑儿的把自己想说的话通通告诉了互联网大哥。然后......
就没有然后了，互联网大哥尽管把A说的话带到了B那里，但B全然没听明确A在说些什么，由于互联网大哥用录音机同一时候记录了A说的好几句话。
本来传话的内容是这种：你好呀！我叫A。我住在A家村！
但播放器播放出来的内容却是这种：你好呀我叫。A我住。在，A家村！
所以，这场原本预料之中无比轻松欢快的交流重新宣告破裂。
【由于数据的接收方收到的仅仅是一长串的字节数值。先不论他知不知道该用什么编码方式进行转换。就算知道了，他将数据转换出来以后也仅仅是一段一段分隔开的内容，或是一长串黏在一起的内容，总之他可不知道接收到的这个数据到底是装了四个int数据呢。还是三个int一个string，还是一张图片】
问题来了：A要传递的话已经到了B的手里，但怎么才干让B理清A要表达的语意呢？
这天，A又和互联网大哥聚在一起。
互联网大哥抱怨说：一定是播放器有问题。我要去找生产厂商投诉。
A提议道：播放器应该没有问题，我想我们能够在传话的内容上做些手脚，比方说，用一些特殊的东西来区分开我说的每一句话。也就是。制定一种规则【传输协议】。
听A这一说。互联网大哥一拍脑门：好主意啊，我想到了一个法子，我们在每句话的前面都加上一个表示你開始说话的词语【消息头】，然后里面记录你这句话说了多少个字【消息头记录的消息体长度】，这种话就算播放器放出来不是连贯的。但B也能依据我们附加的信息看明确你说的话。
想着。互联网大哥立刻就跟A道别离去，也不顾A的挽留，他迫不及待的想要把这种更新潮的想法普及给族里的每一个兄弟姐妹，这种话，他也能帮助B听明确A的传话了。
......
也不知道是过了多久以后，这天互联网大哥再次登门到了A家。
A无比热情的迎接了他。饭后互联网大哥介绍了他们最新的传话规则。以这种规则来传话的话。A说的一句话从播放器放出来大概就是这种格式：
【消息头】A说了一句话，说了三个字【消息体的长度】：【消息体】你好呀！
只是互联网大哥继续说：仅仅只是这种规则的话，为了防止前面的标记（A说了一句话，说了三个字）也被播放器打乱顺序，我们得规定这个标记必须是一个固定的长度，以及一个固定的语法。同一时候这个长度和语法要让B也知道，这种话就算传递到B那里时前面的标记被打乱了（比方在B那里是这样：A说了一，句话说了，三个字）。但B仅仅要依据我们规定的长度（比方这里是：11）和语法就能整理出这个标记，然后再通过这个标记整理出他后面包括的话。从标记中能够看出后面仅仅有三个字是包括在这句话中的，将这三个字：你好呀。提取出来就是一句完整的话，然后 你好呀 后面跟着的又是下一句话的标记，再依据标记的长度固定为11。筛选出11个字。整理出来就是下一句话的标记，然后依据标记中又能够得出下一句话的长度，以此类推......
A一听兴奋了（尽管他压根就没听明确），原来打个招呼最终变得这么简单了，想着他一股脑儿的把自己想说的话通通告诉了互联网大哥，这次，最终成功了。B最终听到了A对他说的话。尽管内容中有非常多不属于原话的标记信息。但B总算是听明确了：
A说了一句话，说了三个字：你好呀！
A说了一句话。说了三个字：我叫A。
A说了一句话，说了六个字：我住在A家村！
同一时候，B也通过A的门牌号和身份证并使用这种互联网家族推行的规则向A回应了一声：
B说了一句话。说了三个字：你好呀。
B说了一句话，说了六个字：非常高兴认识你！
......
至此，这场原本预料之中无比轻松欢快的交流到这里最终轻松欢快的完毕了。
互联网大哥为此感到无比的欣慰，尽管仅仅是为A和B攻克了看似简单的互相传话，但在这之后，他想到了能够把不论什么东西都通过一种方式变成非常多个1和0组成的数据。然后送到指定的门牌号和身份证的人手里。从而实现了一个无比复杂的物流链，那种最初的和A制定的规则也一直延续了下来。
至此。故事讲完了。假设你还是没听懂或者压根就没看明确讲述了什么，那一定是A和B的描写叙述有问题（A：这锅我不背！
B：这锅我不背。），只是。我认为还是有必要进行总结一下。
总结
总结的话大概就是以下两点：
1、【传输层】两台电脑之间要互通消息的话，通过IP地址和port号来确定各自的位置。然后将要传递的数据转化为字节数组（由于眼下仅仅支持传递这种格式的数据，其实全部数据存放在内存中都是这种格式）。进行相互发送和接收，至于传输层，也是有传输协议的。只是这个一般不须要你去管理，提一下，一般仅仅须要你去关心的就是TCP/IP协议。当然还有UDP/IP协议。
2、【应用层】尽管发送方知道自己发送的是什么东西、转化成字节数组之后有多长，但接收方肯定不知道，所以应用层的网络协议诞生了。他规定发送方和接收方必须使用一个固定长度的消息头。消息头必须使用某种固定的组成，并且消息头里必须记录消息体的长度等一系列信息，以方便接收方能够正确的解析发送方发送的数据。
再次整理一下流程：
发送方发送消息 ->
接收方首先依据协议规定的消息头长度（比方30）。取出30个字节 ->
再依据协议规定的消息头编码方式（比方UTF-8），将这30个字节转换为相应数据，也就是得到消息头 ->
再依据协议规定的消息头中的特定位置记录有消息体的长度（比方200），从而在这30个字节之后再取出200个字节 ->
再依据协议规定的消息头中的特定位置记录有消息体的编码方式（比方UTF-8）。对这200个字节进行转换，从而得到与发送方发送时一模一样的数据。
所以说，应用层的网络协议，他旨在让你更方便的应用从网络中接收到的数据。至于数据的传递。没有相似http协议的东西。你也能够直接在两台电脑间开干，仅仅只是传来传去就是一堆1和0组成的字节数组。假设你认为能够看得懂，那也就能够不使用协议了。
在unity中的实际应用样例：Unity C# 自己定义TCP传输协议以及封包拆包、解决粘包问题
转载请注明出处：http://blog.csdn.net/qq992817263/article/details/56669228