439 lines
No EOL
38 KiB
HTML
439 lines
No EOL
38 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>4.2. The TCP/IP Internet Model — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="3. Network Applications and Protocols" href="NetApps.html" />
|
||
<link rel="prev" title="1. Networked Concurrency" href="SocketsOverview.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="FiveLayer.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="FiveLayer.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/FiveLayer.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="SocketsOverview.html">4.1. Networked Concurrency</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="NetApps.html">4.3. Network Applications and Protocols</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "FiveLayer";ODSA.SETTINGS.MODULE_LONG_NAME = "The TCP/IP Internet Model";ODSA.SETTINGS.MODULE_CHAPTER = "Networked Concurrency"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 15:31:50"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="the-tcp-ip-internet-model">
|
||
<h1>4.2. The TCP/IP Internet Model<a class="headerlink" href="FiveLayer.html#the-tcp-ip-internet-model" title="Permalink to this headline">¶</a></h1>
|
||
<p>Modern computing systems rely on the <a class="reference internal" href="Glossary.html#term-internet"><span class="xref std std-term">Internet</span></a> for communication. The Internet is not a
|
||
single computer network. Rather, the Internet is a network of interconnected networks that
|
||
communicate using a common set of <a class="reference internal" href="Glossary.html#term-protocol"><span class="xref std std-term">protocols</span></a>, specifications that define the
|
||
structure and other requirements for messages between computers. The messages originate with
|
||
<a class="reference internal" href="Glossary.html#term-host"><span class="xref std std-term">hosts</span></a>—computers and similar connected devices—at the <a class="reference internal" href="Glossary.html#term-network-edge"><span class="xref std std-term">network edge</span></a>. The messages are
|
||
then passed (or <a class="reference internal" href="Glossary.html#term-forwarding"><span class="xref std std-term">forwarded</span></a>) between <a class="reference internal" href="Glossary.html#term-router"><span class="xref std std-term">routers</span></a>, devices that are
|
||
connected in a way that creates the structure of the network. The <a class="reference internal" href="Glossary.html#term-network-core"><span class="xref std std-term">network core</span></a> that serves
|
||
as the basis of the Internet is the backbone, which refers to the connected networks that are
|
||
controlled and maintained by a few telecommunications companies, such as AT&T and CenturyLink. These
|
||
backbone providers sell access to <a class="reference internal" href="Glossary.html#term-tier-1-internet-service-provider"><span class="xref std std-term">Tier 1 Internet Service Providers</span></a> (ISPs),
|
||
including Level 3, Cogent, and GTT. Note that there is some overlap in these companies, as backbone
|
||
providers can also be Tier 1 ISPs; these companies sell access to the communication lines to each
|
||
other based on <a class="reference internal" href="Glossary.html#term-peering-agreement"><span class="xref std std-term">peering agreements</span></a>.</p>
|
||
<div class="figure mb-2 align-right" id="id2" style="width: 50%">
|
||
<span id="netbackbone"></span><a class="reference internal image-reference" href="_images/CSF-Images.4.1.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Home and enterprise networks connect through local ISPs and the Internet backbone" src="_images/CSF-Images.4.1.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 4.2.1: Home and enterprise networks connect through local ISPs and the Internet backbone</span></p>
|
||
</div>
|
||
<p><a href="FiveLayer.html#netbackbone">Figure 4.2.1</a> illustrates the basic structure of how computer systems connect
|
||
through the Internet. A family may create a home network by setting up a Wi-Fi router that serves as
|
||
an <a class="reference internal" href="Glossary.html#term-access-point"><span class="xref std std-term">access point</span></a> for laptops, smartphones, gaming systems, smart TVs, or other such consumer
|
||
devices. This Wi-Fi router is connected to a local ISP using a subscription service, such as cable
|
||
modem access. The local ISP has an internal network that connects to other ISPs, eventually leading
|
||
to a Tier 1 ISP. Similarly, companies can set up their own enterprise <a class="reference internal" href="Glossary.html#term-local-area-network"><span class="xref std std-term">local area network</span></a>
|
||
(LAN), allowing their computers to exchange data directly. Just like the home user, the company
|
||
running the enterprise LAN would need to have a subscription for service from a local ISP in order
|
||
for their employees to have Internet access. This company may also be acting as a
|
||
<a class="reference internal" href="Glossary.html#term-content-provider"><span class="xref std std-term">content provider</span></a> that creates services such as email, cloud computing data storage, or web sites.</p>
|
||
<div class="section" id="internet-model">
|
||
<h2>4.2.1. Internet Model<a class="headerlink" href="FiveLayer.html#internet-model" title="Permalink to this headline">¶</a></h2>
|
||
<div class="figure mb-2 align-right" id="id3" style="width: 50%">
|
||
<span id="netfivelayer"></span><a class="reference internal image-reference" href="_images/CSF-Images.4.2.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The five layers of Internet communcation" src="_images/CSF-Images.4.2.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 4.2.2: The five layers of Internet communcation</span></p>
|
||
</div>
|
||
<p>Network communication adheres to a layered architecture, which is commonly described using the
|
||
<a class="reference internal" href="Glossary.html#term-internet-model"><span class="xref std std-term">Internet model</span></a>, as illustrated in <a href="FiveLayer.html#netfivelayer">Figure 4.2.2</a>. The <a class="reference internal" href="Glossary.html#term-application-layer"><span class="xref std std-term">application
|
||
layer</span></a> consists of the logical endpoints of the communication within applications; for instance, a
|
||
web browser operating at the application layer at one end may establish a connection to a web server
|
||
running in the application layer at the other endpoint. The applications at the two hosts cannot
|
||
directly communicate. Instead, the application opens a <a class="reference internal" href="Glossary.html#term-socket"><span class="xref std std-term">socket</span></a>, the software endpoint for the
|
||
connection. Sockets can be considered a form of message passing IPC that is primarily used for
|
||
network communication; at either end, the processes write to and read from the socket using system
|
||
calls.</p>
|
||
<p>The sockets provide the process with an interface to the <a class="reference internal" href="Glossary.html#term-transport-layer"><span class="xref std std-term">transport layer</span></a>, which is typically
|
||
implemented in the OS. The transport layer provides some key services that make the network
|
||
communication more usable to the application layer. The transport layer breaks application layer
|
||
messages—which may be large—into fixed-size data <a class="reference internal" href="Glossary.html#term-segment"><span class="xref std std-term">segments</span></a> for delivery. The
|
||
transport layer then provides a <a class="reference internal" href="Glossary.html#term-multiplexing-networking"><span class="xref std std-term">multiplexing</span></a> service, allowing all processes on a single
|
||
host to share a single network connection. At the receiving end, the transport layer performs
|
||
<a class="reference internal" href="Glossary.html#term-demultiplexing"><span class="xref std std-term">demultiplexing</span></a>, directing the data to the appropriate process. Multiplexing and
|
||
demultiplexing are achieved through the use of a <a class="reference internal" href="Glossary.html#term-port-number"><span class="xref std std-term">port number</span></a>, which is an integer associated
|
||
with a particular process; at each host, only a single process can be assigned to a particular port
|
||
number at a time. Furthermore, packets can arrive at their destination out of order, so part of the
|
||
demultiplexing service is to reassemble the application-layer messages in the expected order. For
|
||
instance, when accessing a web page, the browser may send the application-layer message starting
|
||
with <code class="docutils literal notranslate"><span class="pre">"GET</span> <span class="pre">/index.html</span> <span class="pre">HTTP/1.1"</span></code>. The demultiplexing service would ensure the data is read by the
|
||
web server’s socket in that order, rather than <code class="docutils literal notranslate"><span class="pre">"ex.html</span> <span class="pre">HTTP/1.1GET</span> <span class="pre">/ind"</span></code>. It is very unlikely
|
||
that messages this small would be split across multiple packets, but it is common for larger messages.</p>
|
||
<p>As the amount of data sent by applications increases, networks can experience <a class="reference internal" href="Glossary.html#term-congestion"><span class="xref std std-term">congestion</span></a>.
|
||
When this happens, packets can be lost or significantly delayed. To address this problem, some
|
||
transport layer protocols, such as <a class="reference internal" href="Glossary.html#term-transmission-control-protocol"><span class="xref std std-term">Transmission Control Protocol</span></a> (TCP), also provide
|
||
<a class="reference internal" href="Glossary.html#term-flow-control"><span class="xref std std-term">flow control</span></a> and <a class="reference internal" href="Glossary.html#term-reliable-transport"><span class="xref std std-term">reliable transport</span></a> services. When the network is experiencing a
|
||
significant amount of congestion, the flow control will slow down the rate that the host sends new
|
||
packets into the network; with enough hosts doing this, the congestion will gradually drop and the
|
||
performance will increase. When packets are lost in transit, reliable transport will detect the lost
|
||
data and send a request for the data to be resent. TCP is also a <a class="reference internal" href="Glossary.html#term-connection-oriented-protocol"><span class="xref std std-term">connection-oriented
|
||
protocol</span></a>, which means that the two hosts store persistent state information between messages. In
|
||
contrast, <a class="reference internal" href="Glossary.html#term-user-datagram-protocol"><span class="xref std std-term">User Datagram Protocol</span></a> (UDP) is a <a class="reference internal" href="Glossary.html#term-connectionless-protocol"><span class="xref std std-term">connectionless protocol</span></a> that does not
|
||
maintain state between messages; each message that arrives at a server is treated as if it is from a
|
||
new, unique client. UDP is also an <a class="reference internal" href="Glossary.html#term-unreliable-transport"><span class="xref std std-term">unreliable transport</span></a> protocol, meaning that it does not
|
||
attempt to correct errors from lost data.</p>
|
||
<p>When the transport layer needs to send or receive packets, the transport layer protocol contacts the
|
||
<a class="reference internal" href="Glossary.html#term-internet-layer"><span class="xref std std-term">Internet layer</span></a>. The Internet layer provides the logical structure of the connections between
|
||
hosts. That is, while the transport layer provides <a class="reference internal" href="Glossary.html#term-end-to-end-communication"><span class="xref std std-term">end-to-end communication</span></a> for processes on
|
||
the two hosts, the Internet layer provides <em>point-to-point</em> communication between the hosts
|
||
and routers, both within and across network boundaries. The <a class="reference internal" href="Glossary.html#term-internet-protocol"><span class="xref std std-term">Internet Protocol</span></a> (IP) operates
|
||
at this layer, associating a logical identifier—known as an IP address—with a host or router
|
||
connected to the network. Network-layer protocols define the <a class="reference internal" href="Glossary.html#term-routing"><span class="xref std std-term">routing</span></a> path that packets will
|
||
traverse through the Internet. That is, when a local ISP router receives a packet from a subscriber,
|
||
the router examines the intended destination IP address and sends the packet to another router based
|
||
on its best guess for the shortest path to get there.</p>
|
||
<p>The lowest layers of this model are the <a class="reference internal" href="Glossary.html#term-link-layer"><span class="xref std std-term">link</span></a> and <a class="reference internal" href="Glossary.html#term-physical-layer"><span class="xref std std-term">physical</span></a> layers, which are typically designed and implemented together in the hardware devices. The
|
||
reason for this co-design is that the protocol depends on the underlying physical transmission
|
||
technique. A desktop or server may be using the <a class="reference internal" href="Glossary.html#term-ethernet"><span class="xref std std-term">Ethernet</span></a> suite of protocols to send pulses
|
||
of light over a fiber optic cable. A laptop communicating with a Wi-Fi access point may be using the
|
||
<a class="reference internal" href="Glossary.html#term-ieee-802-11"><span class="xref std std-term">IEEE 802.11</span></a> family of protocols that encode bits on radio waves. A smartphone, on the other
|
||
hand, may be using a <em>5G</em> link that uses a different type of radio that requires a different
|
||
encoding technique.</p>
|
||
<p>The link and Internet layers serve a similar purpose, which is to create links between computer
|
||
systems. The key difference is the layer of abstraction at which they operate. Link layer protocols
|
||
can only send packets to other devices within the same network, as they are tied closely to the
|
||
physical connection; for instance, the purpose of Ethernet is to transmit bits between two devices
|
||
that are physically connected by a cable. The Internet layer protocols operate at a higher level of
|
||
abstraction, as two consecutive routers may not be physically connected. Rather, one router may be
|
||
connected to a <a class="reference internal" href="Glossary.html#term-switch"><span class="xref std std-term">network switch</span></a> <a class="footnote-reference" href="FiveLayer.html#f21" id="id1">[1]</a>, a specialized device that provides high-speed packet
|
||
forwarding within a LAN. That switch may be connected to another, which is connected to a third, and
|
||
so on until the other router is reached. These individual point-to-point connections between
|
||
switches may involve different link protocols or versions, such as alternating between the 100BASE-T
|
||
(100 Mbit/s transmission speed) and 10GBASE-T (10 Gbit/s) versions of Ethernet. Thus, what looks
|
||
like a single connection or <a class="reference internal" href="Glossary.html#term-hop"><span class="xref std std-term">hop</span></a> between routers in the Internet layer may require traversing
|
||
several point-to-point links between switches in the link layer.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Note.png"><img alt="Decorative note icon" src="_images/CSF-Images-Note.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Note</p><hr class="mt-1" />
|
||
<p>The Internet model that we have described here is <cite>mostly</cite> based on the official model described in
|
||
RFC 1122, which specifies requirements for Internet hosts. To be precise, RFC 1122 does not include
|
||
the physical layer in the model, but we find it is useful to include for completeness. Other books
|
||
and resources also deviate from RFC 1122 in a variety of ways, such as slightly different naming
|
||
conventions (<em>network layer</em> instead of <a class="reference internal" href="Glossary.html#term-internet-layer"><span class="xref std std-term">Internet layer</span></a>, <em>data link layer</em> or <em>network
|
||
access</em> instead of <a class="reference internal" href="Glossary.html#term-link-layer"><span class="xref std std-term">link layer</span></a>). These details are not generally a major concern, but readers
|
||
should be aware that these variations in terminology exist.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="packet-encapsulation-and-nomenclature">
|
||
<h2>4.2.2. Packet Encapsulation and Nomenclature<a class="headerlink" href="FiveLayer.html#packet-encapsulation-and-nomenclature" title="Permalink to this headline">¶</a></h2>
|
||
<p>As the network data is passed down the protocol stack, each layer’s data needs to be preserved until
|
||
it is ready to be used by the receiver. This is accomplished by encapsulating each layer’s data as
|
||
the payload for the next layer, attaching a metadata header that contains information used by the
|
||
lower layer. For instance, the transport-layer header would indicate if this packet is being sent
|
||
using TCP or UDP, a protocol that does not provide reliable delivery. The headers also may contain
|
||
information about the size of the payload or a checksum of its contents; this information can be
|
||
used to determine if the data has been transmitted correctly or if some or all of it has been lost
|
||
or corrupted.</p>
|
||
<div class="figure mb-2 align-right" id="id4" style="width: 35%">
|
||
<span id="netencaps"></span><a class="reference internal image-reference" href="_images/CSF-Images.4.3.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Data from each layer is encapsulated" src="_images/CSF-Images.4.3.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 4.2.4: Data from each layer is encapsulated</span></p>
|
||
</div>
|
||
<p>A side effect of creating layered architectures like the Internet model is that the final
|
||
composition often exhibits the frustrating characteristic of redundant nomenclature. As each layer
|
||
is defined to be independent of the others, it is common for the protocols at each layer to use
|
||
different terminology for the same idea. <a href="FiveLayer.html#netencaps">Figure 4.2.4</a> illustrates the layer encapsulation for the
|
||
Internet model. Application-layer becomes the payload for a transport-layer <a class="reference internal" href="Glossary.html#term-segment"><span class="xref std std-term">segment</span></a> with a
|
||
header that contains information about the end-to-end delivery between processes. The network-layer
|
||
<a class="reference internal" href="Glossary.html#term-packet"><span class="xref std std-term">packet</span></a> encapsulates a segment with information needed to route the message between hosts.
|
||
The link-layer <a class="reference internal" href="Glossary.html#term-frame"><span class="xref std std-term">frame</span></a> adds a header that facilitates the physical transmission of the
|
||
information within a LAN.</p>
|
||
<p>While different layers use different terms for the same concept, there often is a nuanced difference
|
||
between the two. For instance, a transport-layer segment generally varies considerably in size,
|
||
containing the full contents of a single application-layer payload. On the other hand, network-layer
|
||
packets may take a single segment and break it into multiple <a class="reference internal" href="Glossary.html#term-fragmentation"><span class="xref std std-term">fragments</span></a> that are
|
||
sent independently. Similarly, the term <a class="reference internal" href="Glossary.html#term-datagram"><span class="xref std std-term">datagram</span></a> is often used as a synonym for packet. The
|
||
subtle difference is that <a class="reference internal" href="Glossary.html#term-packet"><span class="xref std std-term">packet</span></a> is generally associated just with the Internet layer, whereas
|
||
<a class="reference internal" href="Glossary.html#term-datagram"><span class="xref std std-term">datagram</span></a> has a looser connotation; <a class="reference internal" href="Glossary.html#term-datagram"><span class="xref std std-term">datagram</span></a> can sometimes be used at other layers to refer to
|
||
the presence of unreliable data transfers. Finally, the terms <em>byte</em> and <a class="reference internal" href="Glossary.html#term-octet"><span class="xref std std-term">octet</span></a> typically
|
||
refer to a collection of eight bits. The difference here is that some architectures use byte to
|
||
denote the basic information unit size, which is allowed to vary; thus, a byte is not always
|
||
guaranteed to be eight bits, whereas an octet must be. Additionally, in some cases, an octet is read
|
||
right-to-left instead of left-to-right; that is, the decimal value 5 may be denoted by the octet
|
||
10100000 instead of 00000101. Oftentimes, these subtle differences in terminology do not have a
|
||
significant impact on the discussion, but it is important to note they exist.</p>
|
||
<table class="docutils footnote" frame="void" id="f21" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="FiveLayer.html#id1">[1]</a></td><td>Note the different terminology for similar devices. The term <a class="reference internal" href="Glossary.html#term-router"><span class="xref std std-term">router</span></a> is used to describe
|
||
a device that operates at the Internet layer; a <a class="reference internal" href="Glossary.html#term-switch"><span class="xref std std-term">switch</span></a> only operates as high as the link layer
|
||
and does not provide the higher layers of the protocol stack.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<div
|
||
id="ModelSumm"
|
||
class="embedContainer"
|
||
data-exer-name="ModelSumm"
|
||
data-long-name="Internet model questions"
|
||
data-short-name="ModelSumm"
|
||
data-frame-src="../../../Exercises/Sockets/ModelSumm.html?selfLoggingEnabled=false&localMode=true&module=FiveLayer&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="550"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="6"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="ModelSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="SocketsOverview.html">4.1. Networked Concurrency</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="NetApps.html">4.3. Network Applications and Protocols</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |