Application Layerطبقة التطبيقات
مقدمة الفصل
ماذا ستتعلم في هذا الفصل
- Conceptual, implementation aspects of network application protocols: transport-layer service models, client-server paradigm, peer-to-peer paradigm.
- Learn about protocols by examining popular application-level protocols: HTTP, FTP, SMTP / POP3 / IMAP, DNS.
أقسام الفصل
- 1Application architecturesمعماريات التطبيقات
- 2Processes, sockets and addressingالعمليات والمقابس والعنونة
- 3App-layer protocols and transport needsبروتوكولات التطبيقات واحتياجات النقل
- 4Internet transport services; securing TCPخدمات النقل في الإنترنت وتأمين TCP
- 5Web and HTTP overviewالويب وHTTP
- 6Non-persistent and persistent HTTPHTTP غير الدائم والدائم
- 7User-server state: cookiesالكعكات (Cookies)
- 8Web caches (proxy server)ذاكرة الويب المؤقتة (الخادم الوكيل)
- 9FTP: the file transfer protocolبروتوكول نقل الملفات FTP
- 10Electronic mail and SMTPالبريد الإلكتروني وSMTP
- 11Mail access protocols: POP3 and IMAPبروتوكولات الوصول إلى البريد: POP3 وIMAP
- 12DNS: domain name systemنظام أسماء النطاقات DNS
تلميح: استخدم أسهم لوحة المفاتيح للتنقل بين الشرائح.
Creating a network appإنشاء تطبيق شبكي
Application architectures
Some network apps (slide 4)
- web
- text messaging
- remote login
- P2P file sharing
- multi-user network games
- streaming stored video (YouTube, Hulu, Netflix)
- voice over IP (e.g., Skype)
- real-time video conferencing
- social networking
- search
- Write programs that run on (different) end systems and communicate over network — e.g., web server software communicates with browser software.
- No need to write software for network-core devices: network-core devices do not run user applications.
- Applications on end systems allows for rapid app development, propagation.
Client-server vs P2Pعميل/خادم مقابل P2P
Application architectures
| Client-server | P2P | |
|---|---|---|
| Always-on server? | Yes: always-on host with permanent IP address | No always-on server |
| Who communicates? |
| Arbitrary end systems directly communicate |
| Scaling | Data centers for scaling | Self scalability: new peers bring new service capacity and new service demands |
| Addresses | Clients may have dynamic IP addresses | Peers intermittently connected and change IP addresses |
| Management | لا تذكر الشرائح شيئًا هنا. | Complex management |
Processes and socketsالعمليات والمقابس
Processes, sockets and addressing
Program running within a host.
Process that initiates communication.
Process that waits to be contacted.
Process sends/receives messages to/from its socket; socket analogous to door.
- Same host: inter-process communication (defined by OS). Different hosts: exchanging messages.
- Sending process shoves message out door and relies on transport infrastructure on other side of door to deliver it to the socket at the receiving process.
- Above the socket: controlled by app developer; below it: controlled by OS.
- Applications with P2P architectures have client processes & server processes.
Addressing processesعنونة العمليات
Processes, sockets and addressing
To receive messages, a process must have an identifier. A host device has a unique 32-bit IP address — but many processes can be running on the same host.
Includes both IP address and port numbers associated with process on host.
What an app-layer protocol definesما يحدده بروتوكول التطبيق
App-layer protocols and transport needs
- Types of messages exchanged
e.g., request, response
- Message syntax
What fields in messages & how fields are delineated
- Message semantics
Meaning of information in fields
- Rules
For when and how processes send & respond to messages
Open protocolsبروتوكولات مفتوحة
- Defined in RFCs
- Allows for interoperability
- e.g., HTTP, SMTP
Proprietary protocolsبروتوكولات مملوكة
- e.g., Skype
What transport service does an app need?احتياجات التطبيق من النقل
App-layer protocols and transport needs
Some apps (e.g., file transfer, web transactions) require 100% reliable data transfer; other apps (e.g., audio) can tolerate some loss.
Some apps (e.g., Internet telephony, interactive games) require low delay to be "effective".
Some apps (e.g., multimedia) require minimum amount of throughput to be "effective"; other apps ("elastic apps") make use of whatever throughput they get.
Encryption, data integrity, …
| Application | Data loss | Throughput | Time sensitive |
|---|---|---|---|
| file transfer | no loss | elastic | no |
| no loss | elastic | no | |
| Web documents | no loss | elastic | no |
| real-time audio/video | loss-tolerant |
| yes, 100's msec |
| stored audio/video | loss-tolerant | same as above | yes, few secs |
| interactive games | loss-tolerant | few kbps up | yes, 100's msec |
| text messaging | no loss | elastic | yes and no |
TCP and UDP servicesخدمات TCP وUDP
Internet transport services; securing TCP
TCP service
- Reliable transport between sending and receiving process
- Flow control: sender won't overwhelm receiver
- Congestion control: throttle sender when network overloaded
- Connection-oriented: setup required between client and server processes
- Does not provide: timing, minimum throughput guarantee, security
UDP service
- Unreliable data transfer between sending and receiving process
- Does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup
| Application | App-layer protocol | Underlying transport |
|---|---|---|
| SMTP [RFC 2821] | TCP | |
| remote terminal access | Telnet [RFC 854] | TCP |
| Web | HTTP [RFC 2616] | TCP |
| file transfer | FTP [RFC 959] | TCP |
| streaming multimedia | HTTP (e.g., YouTube), RTP [RFC 1889] | TCP or UDP |
| Internet telephony | SIP, RTP, proprietary (e.g., Skype) | TCP or UDP |
Securing TCP: SSLتأمين TCP: SSL
Internet transport services; securing TCP
TCP & UDP
- No encryption
- Cleartext passwds sent into socket traverse Internet in cleartext
SSL
- Provides encrypted TCP connection
- Data integrity
- End-point authentication
- Cleartext passwds sent into socket traverse Internet encrypted
SSL is at app layer: apps use SSL libraries, which "talk" to TCP (SSL socket API).
Web and HTTPالويب وHTTP
Web pages
- Web page consists of objects: HTML file, JPEG image, Java applet, audio file, …
- Web page consists of a base HTML-file which includes several referenced objects.
- Each object is addressable by a URL, e.g., www.someschool.edu/someDept/pic.gif — host name www.someschool.edu, path name /someDept/pic.gif.
Web's application layer protocol; client/server model. Client: browser that requests, receives (using HTTP) and "displays" Web objects. Server: Web server sends (using HTTP) objects in response to requests.
HTTP uses TCP
- 1
Client initiates TCP connection (creates socket) to server, port 80.
- 2
Server accepts TCP connection from client.
- 3
HTTP messages exchanged between browser (HTTP client) and Web server (HTTP server).
- 4
TCP connection closed.
Server maintains no information about past client requests. (Protocols that maintain "state" are complex: past history must be maintained; if server/client crashes, their views of "state" may be inconsistent and must be reconciled.)
Non-persistent vs persistent HTTPغير الدائم والدائم
Non-persistent and persistent HTTP
Non-persistent HTTP
- At most one object sent over TCP connection
- Connection then closed
- Downloading multiple objects required multiple connections
Persistent HTTP
- Multiple objects can be sent over single TCP connection between client, server
Non-persistent HTTP: user enters www.someSchool.edu/someDepartment/home.index (text + references to 10 jpeg images)
- 1a
HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80.
- 1b
HTTP server at host www.someSchool.edu waiting for TCP connection at port 80 "accepts" connection, notifying client.
- 2
HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index.
- 3
HTTP server receives request message, forms response message containing requested object, and sends message into its socket.
- 4
HTTP server closes TCP connection.
- 5
HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects.
- 6
Steps 1–5 repeated for each of 10 jpeg objects.
HTTP response timeزمن استجابة HTTP
Non-persistent and persistent HTTP
Time for a small packet to travel from client to server and back.
المسألة
Non-persistent HTTP response time (one object)
الصيغة
response time = 2RTT + file transmission time
خطوات الحل
- One RTT to initiate TCP connection.
- One RTT for HTTP request and first few bytes of HTTP response to return.
- File transmission time.
النتيجة
Non-persistent HTTP response time = 2RTT + file transmission time.
Non-persistent HTTP issues
- Requires 2 RTTs per object
- OS overhead for each TCP connection
- Browsers often open parallel TCP connections to fetch referenced objects
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 encounters a referenced object
- As little as one RTT for all the referenced objects
Cookies: keeping "state"الكعكات
User-server state: cookies
- 1Cookie header line of HTTP response message
- 2Cookie header line in next HTTP request message
- 3Cookie file kept on user's host, managed by user's browser
- 4Back-end database at Web site
Example (slides 27–28)
- 1
Susan visits a specific e-commerce site for the first time.
- 2
When the initial HTTP request arrives, the site creates a unique ID (1678) and an entry in backend database for the ID.
- 3
The HTTP response carries set-cookie: 1678; the browser adds "amazon 1678" to its cookie file.
- 4
Later requests (even one week later) carry cookie: 1678; the server takes cookie-specific action.
- Uses: authorization, shopping carts, recommendations, user session state (Web e-mail).
- Keeping "state": protocol endpoints maintain state at sender/receiver over multiple transactions; cookies: http messages carry state.
- Cookies and privacy: cookies permit sites to learn a lot about you; you may supply name and e-mail to sites.
Web caches (proxy server)الذاكرة المؤقتة للويب
Satisfy client request without involving origin server.
- 1
User sets browser: Web accesses via cache; browser sends all HTTP requests to cache.
- 2
Object in cache: cache returns object.
- 3
Else cache requests object from origin server, then returns object to client.
- Cache acts as both client and server: server for original requesting client; client to origin server.
- Typically cache is installed by ISP (university, company, residential ISP).
- Why Web caching? Reduce response time for client request; reduce traffic on an institution's access link; Internet dense with caches enables "poor" content providers to effectively deliver content (so too does P2P file sharing).
Caching exampleمثال الذاكرة المؤقتة
Web caches (proxy server)
Assumptions
- Avg object size: 100K bits; avg request rate from browsers to origin servers: 15/sec; avg data rate to browsers: 1.50 Mbps
- RTT from institutional router to any origin server: 2 sec; access link rate: 1.54 Mbps; 1 Gbps LAN
المسألة
No cache (slide 32)
الصيغة
total delay = Internet delay + access delay + LAN delay
خطوات الحل
- LAN utilization: 15%
- Access link utilization = 99% — problem!
النتيجة
= 2 sec + minutes + usecs
المسألة
Fatter access link: 154 Mbps (slide 33)
خطوات الحل
- Access link utilization = 9.9%
النتيجة
Total delay = 2 sec + msecs + usecs. Cost: increased access link speed (not cheap!).
المسألة
Install local cache, hit rate 0.4 (slide 35)
المعطيات
- At cache
- 40% of requests
- At origin
- 60% of requests
خطوات الحل
- Data rate to browsers over access link = 0.6 × 1.50 Mbps = .9 Mbps
- Utilization = 0.9/1.54 = .58
- Total delay = 0.6 × (delay from origin servers) + 0.4 × (delay when satisfied at cache) = 0.6 (2.01) + 0.4 (~msecs)
النتيجة
≈ 1.2 secs — less than with 154 Mbps link (and cheaper too!)
FTP: separate control and data connectionsFTP
FTP: the file transfer protocol
Transfer file to/from remote host; client/server model — client: side that initiates transfer (either to/from remote); server: remote host. ftp: RFC 959; ftp server: port 21.
Control connection (TCP, server port 21)
- FTP client contacts FTP server at port 21, using TCP
- Client authorized over control connection
- Client browses remote directory, sends commands
- Control connection: "out of band"
Data connection (TCP, server port 20)
- When server receives file transfer command, server opens 2nd TCP data connection (for file) to client
- After transferring one file, server closes data connection
- Server opens another TCP data connection to transfer another file
Electronic mail: three major componentsمكونات البريد
Electronic mail and SMTP
a.k.a. "mail reader": composing, editing, reading mail messages; e.g., Outlook, Thunderbird, iPhone mail client; outgoing, incoming messages stored on server.
Mailbox contains incoming messages for user; message queue of outgoing (to be sent) mail messages.
Protocol between mail servers to send email messages — client: sending mail server; "server": receiving mail server.
SMTP and the Alice-to-Bob scenarioSMTP: من أليس إلى بوب
Electronic mail and SMTP
SMTP [RFC 2821]
- Uses TCP to reliably transfer email message from client to server, port 25.
- Direct transfer: sending server to receiving server.
- Three phases of transfer: handshaking (greeting), transfer of messages, closure.
Scenario: Alice sends message to Bob
- 1
Alice uses UA to compose message "to" bob@someschool.edu.
- 2
Alice's UA sends message to her mail server; message placed in message queue.
- 3
Client side of SMTP opens TCP connection with Bob's mail server.
- 4
SMTP client sends Alice's message over the TCP connection.
- 5
Bob's mail server places the message in Bob's mailbox.
- 6
Bob invokes his user agent to read message.
Mail access protocols: POP3 vs IMAPPOP3 وIMAP
Mail access protocols: POP3 and IMAP
SMTP
- Delivery/storage to receiver's server
Mail access protocol
- Retrieval from server
- POP: Post Office Protocol [RFC 1939]: authorization, download
- IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored msgs on server
- HTTP: gmail, Hotmail, Yahoo! Mail, etc.
| POP3 | IMAP | |
|---|---|---|
| Where messages live | Downloaded to the client ("download and delete" or "download-and-keep") | Kept all in one place: at server |
| State across sessions | Stateless across sessions | Keeps user state: folder names, message-ID ↔ folder mappings |
| Features | Authorization, download |
|
DNS: services and why not centralizeخدمات DNS
DNS: domain name system
Distributed database implemented in hierarchy of many name servers; application-layer protocol: hosts, name servers communicate to resolve names (address/name translation). Core Internet function, implemented as application-layer protocol — complexity at network's "edge".
DNS services
- Hostname to IP address translation
- Host aliasing: canonical, alias names
- Mail server aliasing
- Load distribution: replicated Web servers — many IP addresses correspond to one name
Why not centralize DNS?
- Single point of failure
- Traffic volume
- Distant centralized database
- Maintenance
- A: doesn't scale!
DNS hierarchy and server typesتسلسل خوادم DNS
DNS: domain name system
Client wants IP for www.amazon.com; 1st approx. (slide 49)
- 1
Client queries root server to find com DNS server.
- 2
Client queries .com DNS server to get amazon.com DNS server.
- 3
Client queries amazon.com DNS server to get IP address for www.amazon.com.
| DNS server type | Role on the slides |
|---|---|
| Root |
|
| TLD | Responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains |
| Authoritative | Organization's own DNS server(s): authoritative hostname-to-IP mappings for its named hosts |
| Local (default) |
|
- TLD examples: Network Solutions maintains servers for .com TLD; Educause for .edu TLD.
- Authoritative servers can be maintained by organization or service provider.
- Local DNS server: does not strictly belong to hierarchy; also called "default name server"; its cache of recent translations may be out of date.
DNS name resolution: iterated vs recursiveالاستعلام التكراري والعودي
DNS: domain name system
Example: host at cis.poly.edu wants the IP address for gaia.cs.umass.edu. Its local DNS server is dns.poly.edu; the authoritative DNS server is dns.cs.umass.edu.
Iterated query (slide 53)
- Contacted server replies with name of server to contact
- "I don't know this name, but ask this server"
- The local DNS server asks root, then TLD, then authoritative server in turn
Recursive query (slide 54)
- Puts burden of name resolution on contacted name server
- Each server forwards the query down the chain and returns the answer
- Heavy load at upper levels of hierarchy?
الخلاصة
أنهيت الدرس
الخطوة التالية: ثبّت المعلومات بالبطاقات، ثم اختبر نفسك بالأسئلة.
ما راجعته في هذا الدرس
- Application architecturesمعماريات التطبيقات
- Processes, sockets and addressingالعمليات والمقابس والعنونة
- App-layer protocols and transport needsبروتوكولات التطبيقات واحتياجات النقل
- Internet transport services; securing TCPخدمات النقل في الإنترنت وتأمين TCP
- Web and HTTP overviewالويب وHTTP
- Non-persistent and persistent HTTPHTTP غير الدائم والدائم
- User-server state: cookiesالكعكات (Cookies)
- Web caches (proxy server)ذاكرة الويب المؤقتة (الخادم الوكيل)
- FTP: the file transfer protocolبروتوكول نقل الملفات FTP
- Electronic mail and SMTPالبريد الإلكتروني وSMTP
- Mail access protocols: POP3 and IMAPبروتوكولات الوصول إلى البريد: POP3 وIMAP
- DNS: domain name systemنظام أسماء النطاقات DNS