A Critique of the Models and Protocols of OSI & TCP/IP
2014-01-03 09:38
441 查看
Neither the OSI model and its protocols nor the TCP/IP model and its protocols are perfect. The criticism of the OSI model and its protocols can be summarized as:
1. Bad timing.
2. Bad technology.
3. Bad implementations.
4. Bad politics.
Bad timing
The competing TCP/IP protocols were already in widespread use by research universities by the time the OSI protocols appeared. While the billion-dollar
wave of investment had not yet hit, the academic market was large enough that many vendors had begun cautiously offering TCP/IP products. When OSI came around, they did not want to support a second protocol stack until they were forced to, so there were no
initial offerings. With every company waiting for every other company to go first, no company went first and OSI never happened.
Bad Technology
The second reason that OSI never caught on is that both the model
and the protocols are flawed. The choice of seven layers was more political than technical, and two of the layers (session and presentation) are nearly empty, whereas two other ones (data link and network) are overfull.
The OSI model, along with its associated service definitions
and protocols, is extraordinarily complex. They are also difficult to implement and inefficient in operation.
In addition to being incomprehensible, another problem with OSI is that some functions, such as addressing, flow control, and error control, reappear again and again in each layer.
Bad Implementations
Given the enormous complexity of the model and the protocols, it will come as no surprise that the initial implementations were huge, unwieldy, and slow. It did not take long for people to associate "OSI" with "poor quality". Although
the products improved in the course of time, the image stuck.
In contrast, one of the first implementations of TCP/IP was part of Berkeley UNIX and was quite good. People began using it quickly, which led to a large user community, which led to improvements, which led to an even larger community.
Here the spiral was upward instead of downward.
Bad Politics
On account of the initial implementation, many people, especially in academia, thought of TCP/IP as part of UNIX, and UNIX in the 1980s in academia was not unlike parenthood and apple pie.
OSI, on the other hand, was widely thought to be the creature
of the European telecommunication ministries. The very idea of a bunch of government bureaucrats trying to shove a technically inferior standard down the throats of the poor researchers and programmers down in the trenches actually developing computer networks
did not aid OSI's cause.
The TCP/IP model and protocols have their problems too. First, the model does not clearly distinguish the concepts of services, interfaces, and protocols. Good software engineering practice requires differentiating between the specification
and the implementation, something that OSI does very carefully, but TCP/IP does not. Consequently, the TCP/IP model is not much of a guide for designing new networks using new technologies.
Second, the TCP/IP model is not at all general and is poorly suited to describing any protocol stack other than TCP/IP. Trying to use the TCP/IP model to describe Bluetooth, for example, is completely impossible.
Third, the link layer is not really a layer at all in the normal
sense of the term as used in the context of layered protocols. It is an interface (between the network and data link layers). The distinction between an interface and layer is crucial and one should not be sloppy about it.
Fourth, the TCP/IP model does not distinguish between the physical
and data link layers. These are completely different. The physical layer has to do with the transmission characteristics of copper wire, fiber optics, and wireless communication. The data link layer's job is to delimit the start and end of frames and get them
from one side to the other with the desired degree of reliability. A proper model should include both as separate layers. The TCP/IP model does not do this.
Finally, although the IP and TCP protocols were carefully thought
out and well implemented, many of the other protocols were ad hoc, generally produced by a couple of graduate students hacking away until they got tired. The protocol implementations were then distributed free, which resulted in their becoming widely used,
deeply entrenched, and thus hard to replace. Some of them are a bit of an embarrassment now.
1. Bad timing.
2. Bad technology.
3. Bad implementations.
4. Bad politics.
Bad timing
The competing TCP/IP protocols were already in widespread use by research universities by the time the OSI protocols appeared. While the billion-dollar
wave of investment had not yet hit, the academic market was large enough that many vendors had begun cautiously offering TCP/IP products. When OSI came around, they did not want to support a second protocol stack until they were forced to, so there were no
initial offerings. With every company waiting for every other company to go first, no company went first and OSI never happened.
Bad Technology
The second reason that OSI never caught on is that both the model
and the protocols are flawed. The choice of seven layers was more political than technical, and two of the layers (session and presentation) are nearly empty, whereas two other ones (data link and network) are overfull.
The OSI model, along with its associated service definitions
and protocols, is extraordinarily complex. They are also difficult to implement and inefficient in operation.
In addition to being incomprehensible, another problem with OSI is that some functions, such as addressing, flow control, and error control, reappear again and again in each layer.
Bad Implementations
Given the enormous complexity of the model and the protocols, it will come as no surprise that the initial implementations were huge, unwieldy, and slow. It did not take long for people to associate "OSI" with "poor quality". Although
the products improved in the course of time, the image stuck.
In contrast, one of the first implementations of TCP/IP was part of Berkeley UNIX and was quite good. People began using it quickly, which led to a large user community, which led to improvements, which led to an even larger community.
Here the spiral was upward instead of downward.
Bad Politics
On account of the initial implementation, many people, especially in academia, thought of TCP/IP as part of UNIX, and UNIX in the 1980s in academia was not unlike parenthood and apple pie.
OSI, on the other hand, was widely thought to be the creature
of the European telecommunication ministries. The very idea of a bunch of government bureaucrats trying to shove a technically inferior standard down the throats of the poor researchers and programmers down in the trenches actually developing computer networks
did not aid OSI's cause.
The TCP/IP model and protocols have their problems too. First, the model does not clearly distinguish the concepts of services, interfaces, and protocols. Good software engineering practice requires differentiating between the specification
and the implementation, something that OSI does very carefully, but TCP/IP does not. Consequently, the TCP/IP model is not much of a guide for designing new networks using new technologies.
Second, the TCP/IP model is not at all general and is poorly suited to describing any protocol stack other than TCP/IP. Trying to use the TCP/IP model to describe Bluetooth, for example, is completely impossible.
Third, the link layer is not really a layer at all in the normal
sense of the term as used in the context of layered protocols. It is an interface (between the network and data link layers). The distinction between an interface and layer is crucial and one should not be sloppy about it.
Fourth, the TCP/IP model does not distinguish between the physical
and data link layers. These are completely different. The physical layer has to do with the transmission characteristics of copper wire, fiber optics, and wireless communication. The data link layer's job is to delimit the start and end of frames and get them
from one side to the other with the desired degree of reliability. A proper model should include both as separate layers. The TCP/IP model does not do this.
Finally, although the IP and TCP protocols were carefully thought
out and well implemented, many of the other protocols were ad hoc, generally produced by a couple of graduate students hacking away until they got tired. The protocol implementations were then distributed free, which resulted in their becoming widely used,
deeply entrenched, and thus hard to replace. Some of them are a bit of an embarrassment now.
相关文章推荐
- 网络连接相关类
- HI3531网络tftp、nfs加载
- HI3531网络tftp、nfs加载
- HI3531网络tftp、nfs加载
- 第一个 node js http 发送post请求(测试无误)
- HI3531网络tftp、nfs加载 分类: arm-linux-Ubuntu HI3531 2014-01-03 09:11 826人阅读 评论(0) 收藏
- Go 的 HTTP 工具
- 计算机网络学习-网络层
- 关于LINUX修改网络IP
- 三星t959手机"sim卡网络解锁pin码"处理方法
- wamp中的httpd.conf文件设置
- TCP 网络拥塞控制
- 07-Tomcat 输入http://localhost:8080看不到猫
- spring mvc HttpServletRequest
- Android网络编程实践之旅
- TCP/IP传输层,你懂多少?
- TCP超时重传算法
- http://stackoverflow.com/questions/19157977/ld-symbol-dyld-stub-binding-helper-not-found-normally-in
- linux TCP发送源码学习(1)--tcp_sendmsg
- linux TCP发送源码学习(2)--tcp_write_xmit