Early computer networks, such as ARPANET, were designed for government and military applications. As an increasing number of researchers worked on these technologies, there was a growing push to standardize the communication protocols and open access to academic and commercial interests. Vint Cerf introduced the term Internet in RFC 675 (1974) as part of the first specification of TCP, and the name stuck. The TCP/IP protocol suite was later standardized in 1982, with the Internet emerging as the public successor of ARPANET. .. topic:: Chapter Objectives .. figure:: Images/CSF-Images-Objectives.png :align: left :figwidth: 5% :width: 100% :alt: Decorative chapter objectives image In this chapter, we will address the following instructional objectives: * We will describe the principles of application-layer overlay networks. * We will compare and contrast the functioning of the UDP and TCP transport-layer protocols. * We will explore how cryptography can be used to provide secure network communication. * We will summarize how the network and link layers deliver messages through the Internet. * We will consider how wireless technologies different from traditional wired networks. The previous chapter introduce the socket API as a mechanism that appears to behave like other forms of IPC. Using the socket API, the application can use traditional ``read()`` and ``write()`` functions or the equivalent ``sendto()`` and ``recvfrom()`` to exchange data with other processes. From this perspective, building networked applications bears many similarities to traditional single-host concurrent software. The key differences arise at the design stage. Networked applications can face a dilemma that other forms of concurrent software do not. For example, assume that a process correctly formats a message and sends it into the socket. At the other end, the receiver has correctly prepared to receive the message, but the message never arrives. In other forms of IPC, the processes could check error codes provided by the OS to determine what went wrong. In the network, however, there is no OS. The sender believes it was successful at its end and hopes for the best for the message delivery. The receiver only knows the data did not arrive; it cannot tell if the data was lost in transit or if the sender itself failed. Architects of networked applications must consider how to handle this scenario. Some socket configurations request the lower layers of the protocol stack fix the problem; the lower layers may still fail, but they will at least try. In other configurations, the application itself can accept responsibility for handling the fault, either by re-sending the request, displaying an error message, or downgrading the quality of the application service (such as showing a pixelated version of the image or pausing a video playback while more data is being buffered). This design choice entails selecting an appropriate transport-layer protocol. While it may seem that reliability is always required, that is not necessarily so. To properly design networked applications, it is important to understand how the layers of the network fit together. In this chapter, we will explore the full protocol stack of the :term:`Internet model`. Starting at the top, we will start with the overall system architecture of the application, along with how the transport layer protocols influence the design. In addition, we will explore the capabilities and functioning of the lower protocol layers, which can influence application design choices. This overview includes an introduction to available security services, how hosts are located, and how data is actually transmitted. This chapter necessarily omits some details to create a foundational understanding of the key concepts of these layers. Interested readers should explore the details in the recommended resources.“The stuff I design, if I’m successful, nobody will ever notice. Things will just work, and be self-managing.”