Week 3 Summary PDF
Document Details
Tags
Summary
This document provides a summary of week 3's content on networking concepts. It covers client-server and peer-to-peer architectures, sockets, and various network applications. The focus is on foundational networking principles.
Full Transcript
Week 3 Summary \[1\] Client-server architecture - In a client-server architecture, there is an always-on host called the server (services requests from many other hosts/browsers (clients)) - Clients do not directly communicate with each other - Server has a fixed, well-known addres...
Week 3 Summary \[1\] Client-server architecture - In a client-server architecture, there is an always-on host called the server (services requests from many other hosts/browsers (clients)) - Clients do not directly communicate with each other - Server has a fixed, well-known address (IP address) - Some applications, for example, Web, FTP, Telnet, email \[2\] Peer-to-peer (P2P) Architecture - There is minimal or no reliance on dedicated servers in the data center - The application exploits direct communication between pairs of intermittently connected hosts (peers) - Peers are not owned by the service provider, but desktops and laptops controlled by user - Peers communicate without passing through a dedicated server - Many of today's traffic intensive application is based on P2P: file sharing, internet telephony and video conferencing \[3\] Socket - Is the interface between the application layer and the transport layer within a host - Sits below the application layer and the interface of the transport layer - Is a process to send messages into and receive messages from the network through a software interface - Socket pair: a combination of IP address and port number \[4\] Some network apps - Social networking and web - Text-messaging and email - Voice over IP - Real time video conferencing - Internet search and remote login - Multi user network games - Streaming stored video - P2P file sharing \[5\] Creating a network app - Write a program that run on various end systems, communication over network - Network core devices do not run user application - Application on end systems allows for rapid app development and propagation \[6\] Client-server paradigm - Server: - Always on host - Permanent IP address - Often in data center for scaling - Clients: - Contact and communicate with server - May be interminently connected - May have dynamic IP address - Do not communicate directly with each other - Ex: HTTP, IMAP, FTP \[7\] peer-peer architecture - No always on server - Arbitrary end systems directly communicates - Peer request service from other peers, provide service in return to other peers (self scalability -\> new peers bring new service capacity as well as service demands) - Peers are intermittently connected and change IP addresses (complex management) - Ex: P2P file sharing \[8\] Process communicating - Process : program running within a host - Within same host, two processes communicate using inter-process communication (define by OS) - Processes in different hosts communicate by exchanging messages - Client process : process that initiates communication - Server process : process that wait to be contacted - Applications with P2P architecture have client process and server process \[9\] Sockets (Pt.2) - Process sends or receives messages to or from its sockets - Socket analogous to doors - Sending process shoves message out door - Sending process relies on transport infrastructure on the other sode of dopr to deliver message to socket at receiving process - Two sockets involved (one on each side) \[10\] Addressing process - To receive message, process must have identifier - Host device has unique 32 bit IP address - Many process can run in the same host - Identifier includes both IP address and port numbers associated with process on host \[11\] Reliable data transfer - Some applications can be described as loss-tolerant applications \[12\] Throughput - Application that have minimum throughput requirements are said to be bandwidth sensitive applications - Elastic application can make use of as much, or as little available throughput \[13\] Timing - Interactive real time application such as internet telephony requires tight timing constrains on data delivery \[14\] Application layer protocol defines: - Types of messages exchanged (request or response) - Message syntax (in what fields in messages or how it delinated) - Message semantics (meaning of information in fields) - Rules (for when and how process send and respon to message) - Open protocols: defined in RCFs, everyone has access to protocol definition \| allows for interoperability - Proprietary protocols \[15\] What transport service does an app need: - Data integrity -\> some apps (file transfer, web transactions) require 100% reliable data transfer, other apps can tolerate some loss - Timing -\> some apps require low delay to be effective - Throughput -\> some apps require minimum amount of throughput to be effective - Security -\> encryption, data integrity \[16\] Transport service requirements: common apps \[17\] Internet transport protocols service - TCP service: - Reliable transport(between sending and receiving) - Flow control (sender won't overwhelm receiver) - Congestion control (throttle sender when network overloaded) - Does not provide (timing, minimum throughput guarantee, security) - Connection-oriented (setup required between client and server process) - UDP service: (faster than TCP) - Unreliable data transfer (between sending and receiving process) - Does not provide (reliability, flow control, congestion control, timing, throughput guarantee, security or connection setup) ![](media/image2.png) \[18\] Web terminology - A web page (also called a document) consists of objects - A web object is a file such as as HTML file, a JPEG image, a Java applet, or a video clip that is addressable by a single URL - The base HTML file references the other objects on the page with the objects' URL - A screenshot of a computer Description automatically generated \[19\] HTTP overview - HTTP : hypertext transfer protocol - Is a web application layer protocol - Client -\> browser that request, receive, using the HTTP protocol and displays the web objects - Server -\> web server sends (using HTTP protocol) objects in response to request - HTTP uses TCP - Client initiates TCP connection (creates socket) to server, port 80 - Server accepts TCP connection from client - HTTPS messages exchange between browser and web server - TCP connection closed - HTTP is stateless -\> server maintains no information about past clipping requests - Protocols that maintain state are complec -\> past history must be maintained, if server/client crashes, their views of state may be inconsistent and must be reconciled - Non-persistent HTTP - TCP connection opened - At most one object sent over TCP connection - TCP connection closed - Downloading multiple objects required multiple connection - Persistent HTTP - TCP connection opened to server - Multiple objects can be sent over single TCP connection between client and server - TCP connection closed \[20\] Non-persistent HTTP: response time - RTT (definition) -\> time for a small packet to travel from client to server and back - HTTP response time (per object) -\> one RTT to initiate TCP connection, one RTT for HTTP request and first few bytes of response to return - Object/file transmission time - 2RTT + file transmission time \[21\] Persistent HTTP - Non persistent HTTP issues: - Requires 2 RTTs per object - OS overhead for each TCP connection - Browser often opens multiple parallel TCP connections to fetch referenced objects in parallel - Persistent HTTP - Server leaves connection open after sending response - Subsequent HTTP messages between same client/server sent over open connection - Client sends requests as soon as it encountners a referenced object - As little as one RTT for all referenced object (cutting the response time by half) \[22\] HTTP request message - Two types of HTTP messages -\> request, response - HTTP request message -\> ASCII (human-readable format) - ![](media/image4.png) \[23\] HTTP response message - HTTP response message has three sections -\> initial status line, header line, and entity-body \[24\] User-server state: cookies - A diagram of a computer server Description automatically generated - A website will want to identify users using cookies - Cookies allow sites to keep track of the user - Usually used when the web site/server wishes to restrict user access or wants to serve content as a function of the user identity. - Cookie -\> - A cookie header line in the HTTP response message - A cookie header line in the HTTP request message - A cookie file kept on the user's end system and manages by the user's browser - A back-end database at the web-site \[25\] Web cache - Also called a proxy server - Has its own disk storage and keeps copies of recently requested objects in this storage - Once browser is configured, each browser request for an object is directed to the web cache - Typically purchased and installed by an ISP - Web caching has seen deployment on the internet for two reason: - Web cache can substantially reduce the response time for a client request - Can substantially reduce traffic on an institution's access link to the internet - Can substantially reduce web traffic on the internet, therefore improving performance for all applications