Chapter 2 Application layer

• Chỉ một đối tượng web được gửi qua liên kết TCP
• Sử dụng mặc định trong HTTP/1.0
• HTTP 1.0: RFC 1945

RTT (definition): time for a small packet to travel from client to server and back

• Nhiều đối tượng có thể được gửi qua một liên kết TCP
• Sử dụng mặc định trong HTTP/1.1
• HTTP 1.1: RFC 2068

• Mã ASCII (dễ dàng đọc được dưới dạng văn bản)

• General format

• Các phương thức HTTP Request

  HTTP/1.0

  • GET
  • POST
  • HEAD
    • Chỉ các tiêu đề (headers) của yêu cầu sẽ được trả về nếu URL được chỉ định được yêu cầu bằng phương thức HTTP GET.

  HTTP/1.1

  • GET, POST, HEAD
  • PUT
    • Tải file lên máy chủ, đường dẫn chỉ ra trong URL, file để trong body
  • DELETE
    • Xóa file chỉ ra bởi đường dẫn

  Lưu ý: Có 2 cách để gửi tham số đến server: POST hoặc GET

  Ví dụ: http://www.google.com/search?q=computer+network&flags=68&num=10

• General format:
• Mã trạng thái của các thông điệp:

Cookies có thể được sử dụng để:

• Theo dõi hành vi của người dùng trên một trang web cụ thể (cookie bên thứ nhất).
• Theo dõi hành vi của người dùng trên nhiều trang web khác nhau (cookie bên thứ ba) mà không cần người dùng truy cập trực tiếp vào trang web theo dõi (!).

Việc theo dõi có thể không hiển thị đối với người dùng:

• Thay vì một quảng cáo hiển thị kích hoạt HTTP GET đến trình theo dõi, có thể sử dụng một liên kết vô hình.

Theo dõi bên thứ ba qua cookies:

• Bị vô hiệu hóa theo mặc định trên trình duyệt Firefox, Safari.
• Sẽ bị vô hiệu hóa trên Chrome vào năm 2023.

• Giảm thời gian phản hồi cho yêu cầu của máy khách

  • Vì bộ nhớ đệm gần máy khách hơn

• Giảm lưu lượng trên đường truyền của tổ chức

• Internet chứa nhiều bộ nhớ đệm

  • Giúp các nhà cung cấp nội dung có tài nguyên hạn chế phân phối nội dung hiệu quả hơn

Chúng ta có thể thấy trường hợp trên tình trạng tắc nghẽn khá cao vậy cách tối ưu chúng ta thử tăng access link xem sao.

Có vẽ cách trên thật sự tốt nhưng chi phí làm ra access link có tốc độ như trên sẽ rất đắt. Bây giờ chúng ta thử sử dụng web cache

• User agents (UA)
  • Lấy thư từ máy chủ
  • Soạn thư, trả lời, chuyển tiếp, lưu trữ
  • Ví dụ: Outlook, Thunderbird, Apple Mail
• Mail servers
  • Chứa hộp thư đến của NSD (mail box)
  • Hàng đợi để gửi thư đi
  • Ví dụ: Sendmail, Microsoft Exchange,…
• Giao thức:
  • Chuyển thư : SMTP - Simple Mail Transfer Protocol
  • Nhận thư:
    • POP - Post Office Protocol
    • IMAP - Internet Mail Access Protocol

Tài liệu mô tả: RFC (5321)

• Sử dụng TCP để truyền tải tin nhắn email một cách đáng tin cậy từ máy khách (mail server khởi tạo kết nối) đến máy chủ, qua cổng 25.

• Truyền tải trực tiếp: Máy chủ gửi đóng vai trò như client, gửi email đến máy chủ nhận.

• Ba giai đoạn chính của quá trình truyền tải:

  1. SMTP handshaking (chào hỏi, thiết lập kết nối)
  2. SMTP transfer of messages (truyền tải nội dung email)
  3. SMTP closure (đóng kết nối)

• Giao tiếp theo kiểu lệnh/phản hồi, tương tự như HTTP:

  • Lệnh: Được gửi dưới dạng văn bản ASCII
  • Phản hồi: Gồm mã trạng thái (status code) và thông điệp phản hồi

• POP: Post Office Protocol [RFC 1939]
  • Đăng nhập và lấy hết thư về user agent
• IMAP: Internet Mail Access Protocol [RFC 1730]
  • Phức tạp hơn POP
  • Cho phép lưu trữ và xử lý thư trên máy chủ

• HTTP chủ yếu dùng để lấy dữ liệu (pull-based), còn SMTP dùng để gửi dữ liệu (push-based).
• SMTP cần đảm bảo tin nhắn đúng chuẩn 7-bit ASCII, trong khi HTTP linh hoạt hơn.
• SMTP sử dụng kết nối liên tục để truyền nhiều thư trong một phiên làm việc.

• IP address: 32-bit used for addressing datagrams
• ’name’, e.g., cs.umass.edu - used by humans

• Cơ sở dữ liệu phân tán được triển khai theo hệ thống phân cấp của nhiều máy chủ tên miền (name servers).
• Giao thức tầng ứng dụng: Các máy chủ DNS và thiết bị (host) giao tiếp để phân giải tên miền (dịch từ tên miền sang địa chỉ IP và ngược lại).
• Chức năng cốt lõi của Internet, nhưng được triển khai dưới dạng một giao thức tầng ứng dụng.
• Sự phức tạp nằm ở “rìa” mạng (edge network), giúp mạng lõi đơn giản hơn.

Client wants IP address for www.amazon.com; 1st approximation:

• client queries root server to find .com DNS server
• client queries .com DNS server to get amazon.com DNS server
• client queries amazon.com DNS server to get IP address for www.amazon.com

Khi một máy chủ (host) gửi truy vấn DNS, nó sẽ được gửi đến máy chủ DNS cục bộ (Local DNS server).

Máy chủ DNS cục bộ sẽ phản hồi theo hai cách:

• Trả lời từ bộ nhớ cache chứa các cặp ánh xạ tên miền - địa chỉ IP gần đây (có thể đã lỗi thời!).
• Chuyển tiếp yêu cầu vào hệ thống phân cấp DNS để tìm kiếm kết quả chính xác.

Mỗi nhà cung cấp dịch vụ Internet (ISP) đều có máy chủ DNS cục bộ. Cách kiểm tra máy chủ DNS của bạn:

• MacOS: Chạy lệnh scutil --dns
• Windows: Chạy lệnh ipconfig /all

Lưu ý: Máy chủ DNS cục bộ không thuộc hệ thống phân cấp DNS một cách chặt chẽ nhưng đóng vai trò quan trọng trong quá trình phân giải tên miền.

• Giao thức tầng ứng dụng: DNS
• Sử dụng dịch vụ UDP/TCP với cổng dịch vụ là 53

Phân giải tên miền đệ quy (Recursive Query)

Phân giải tương tác (Interactive Query)

• Caching: Máy chủ DNS cục bộ lưu trữ các cặp ánh xạ tên miền - địa chỉ IP gần đây.
• Cập nhật bản ghi: Máy chủ DNS cục bộ sẽ cập nhật bản ghi DNS sau mỗi thời gian nhất định.
• Nhược điểm: Các mục trong cache có thể lỗi thời. Nếu một máy chủ thay đổi địa chỉ IP, thông tin này có thể không được cập nhật ngay lập tức trên toàn Internet cho đến khi TTL của tất cả các bản ghi cũ hết hạn

• Type=A: ánh xạ tên miền - địa chỉ IP
• Type=NS: máy chủ tên miền cấp cao hơn
• Type=CNAME: tên miền chuyển hướng
• Type=MX: máy chủ thư

DNS query and reply messages, both have same format:

Example

Các cuộc tấn công DDoS:

• Tấn công vào các máy chủ chính của hệ thống DNS với lượng truy cập lớn.
  • Hiện tại chưa có thành công lớn.
  • Có thể lọc lưu lượng.
  • Các máy chủ DNS cục bộ có thể bỏ qua máy chủ chính.
• Tấn công vào các máy chủ TLD (Top-Level Domain) cũng rất nguy hiểm.

Các cuộc tấn công giả mạo:

• Can thiệp vào các truy vấn DNS và trả về thông tin sai lệch.
  • Có thể làm hỏng bộ nhớ cache DNS.
  • Liên quan đến dịch vụ xác thực DNSSEC.

• Không có máy chủ luôn hoạt động: Các hệ thống có thể giao tiếp trực tiếp với nhau.

• Các bên ngang hàng yêu cầu dịch vụ: Các bên có thể yêu cầu dịch vụ từ nhau và trả lại dịch vụ.

• Tự mở rộng: Các bên mới tham gia có thể mang theo năng lực và nhu cầu dịch vụ mới.

• Kết nối không liên tục: Các bên có thể thay đổi địa chỉ IP, tạo ra sự phức tạp trong kết nối.

• Ví dụ: Chia sẻ tệp P2P (BitTorrent), phát trực tuyến (KanKan), VoIP (Skype).

[!WARNING]

File distribution time: client-server

File distribution time: P2P

Peer tham gia:

• Không có phần nào khi mới tham gia, sẽ tích lũy dần từ các peer khác.
• Đăng ký với tracker để tìm danh sách peer và kết nối với một số peer.

Tải xuống và chia sẻ:

• Trong khi tải xuống, peer cũng tải lên các phần cho peer khác.
• Trao đổi các phần với nhau, tạo mạng lưới chia sẻ hiệu quả.

Chiến lược chia sẻ:

• Peer yêu cầu các phần còn thiếu từ các peer khác.
• Gửi phần theo kiểu “tit-for-tat” để khuyến khích chia sẻ công bằng.

• Lưu lượng video: Là người tiêu thụ chính băng thông Internet, với Netflix, YouTube, Amazon Prime chiếm khoảng 80% lưu lượng ISP.
• Thách thức về quy mô: Làm thế nào để phục vụ gần 1 tỷ người dùng?
• Thách thức về tính đồng nhất: Các thiết bị có khả năng khác nhau (cố định, di động) và băng thông cũng khác nhau (cao vs thấp).
• Giải pháp: Cơ sở hạ tầng phân tán, ứng dụng CDN (Mạng phân phối nội dung).

• CBR (Bitrate cố định): Tốc độ mã hóa video không thay đổi.
• VBR (Bitrate thay đổi): Tốc độ mã hóa thay đổi tùy theo sự thay đổi không gian và thời gian.
• Ví dụ: MPEG 1 (1.5 Mbps), MPEG 2 (3-6 Mbps), MPEG 4 (64 Kbps - 12 Mbps thường sử dụng trong Internet).

Thách thứ chính:

• Băng thông thay đổi theo thời gian do mức độ tắc nghẽn mạng thay đổi.
• Mất gói tin và độ trễ do tắc nghẽn, có thể làm chậm phát video hoặc gây chất lượng kém

• Ràng buộc phát liên tục: Khi video bắt đầu phát, phát lại phải khớp với thời gian gốc. Tuy nhiên, độ trễ mạng thay đổi (jitter), nên cần bộ đệm phía client để đảm bảo phát mượt mà.
• Các thách thức khác:
  • Tính tương tác của client: Tạm dừng, tua nhanh, tua lại, nhảy đến phần khác của video.
  • Mất gói dữ liệu có thể xảy ra và cần được truyền lại.

Có hình ảnh minh họa quá trình buffering, cho thấy vấn đề xảy ra khi bộ đệm không đủ dữ liệu để phát liên tục.

Bộ đệm phía client và độ trễ phát lại có vai trò quan trọng trong việc đảm bảo trải nghiệm phát video mượt mà bằng cách:

• Bù đắp độ trễ do mạng: Khi có độ trễ từ mạng (do tắc nghẽn, khoảng cách truyền dữ liệu, v.v.), bộ đệm phía client giúp lưu trữ một phần dữ liệu trước khi phát, tránh bị gián đoạn.
• Giảm tác động của jitter (biến động độ trễ): Jitter xảy ra khi các gói dữ liệu đến không đều, gây ra gián đoạn nếu không có bộ đệm. Bộ đệm giúp làm mượt luồng dữ liệu trước khi phát để đảm bảo phát lại ổn định.

Tuy nhiên, độ trễ phát lại (playout delay) cần được điều chỉnh phù hợp:

• Độ trễ cao giúp video ổn định hơn nhưng làm tăng thời gian chờ.
• Độ trễ thấp giúp phát nhanh hơn nhưng có nguy cơ bị gián đoạn nếu mạng không ổn định.

DASH (Dynamic Adaptive Streaming over HTTP) là một phương pháp streaming multimedia hiệu quả.

• Về mặt cấu trúc:
  • Video được chia thành nhiều “chunk” (mảnh).
  • Mỗi chunk được mã hóa với các tỷ lệ khác nhau
• Về mặt máy chủ:
  • Máy chủ lưu trữ nhiều phiên bản của video với các tỷ lệ khác nhau
• Về mặt client:
  • Liên tục đo lường băng thông từ máy chủ đến client.
  • Yêu cầu từng chunk một theo thứ tự.
  • Chọn tỷ lệ mã hóa tối đa dựa trên băng thông hiện có.
  • Có khả năng chọn các tỷ lệ mã hóa khác nhau tại các thời điểm khác nhau, tùy thuộc vào băng thông sẵn có.

Thách thức lớn: Việc phát trực tuyến nội dung từ hàng triệu video đến hàng trăm người dùng cùng lúc là một vấn đề phức tạp.

Giải pháp: Sử dụng CDN để lưu trữ và phục vụ nhiều bản sao video tại các địa điểm khác nhau trên toàn cầu, giúp cải thiện tốc độ truy cập và giảm độ trễ.

Nhà cung cấp nội dung cung cấp dịch vụ qua Internet mà không cần sử dụng cơ sở hạ tầng truyền thống (các nhà cung cấp dịch vụ Internet).

Thách thức trong mô hình OTT:

• Lựa chọn node CDN: Làm thế nào để quyết định từ node nào để lấy nội dung.
• Hành vi người xem: Cách người xem tương tác với nội dung khi mạng bị tắc nghẽn.
• Quản lý nội dung: Xác định nội dung nào nên được lưu trữ ở đâu trong các node CDN để tối ưu hóa hiệu suất.

• Socket: đối tượng dịch vụ do tầng giao vận cung cấp
  • Các tiến trình ứng dụng sử dụng dịch vụ của tầng giao vận để trao đổi thông điệp
• Địa chỉ socket: Địa chỉ IP, Số hiệu cổng
• Ví dụ: Socket mà phần mềm Web Server trên máy chủ của SoICT có định danh 202.191.56.65:80

• UDP (User Datagram Protocol):
  • Không tin cậy (unreliable).
  • Dữ liệu được gửi dưới dạng datagram (gói tin) mà không có đảm bảo về việc truyền tải.
• TCP (Transmission Control Protocol):
  • Tin cậy (reliable).
  • Dữ liệu được gửi dưới dạng luồng byte (byte stream-oriented) và đảm bảo rằng tất cả dữ liệu sẽ được nhận đúng thứ tự.

• UDP (User Datagram Protocol):
  • Không thiết lập kết nối giữa client và server.
  • Không có quá trình bắt tay trước khi gửi dữ liệu.
• Cách thức hoạt động:
  • Người gửi gắn địa chỉ IP đích và số cổng vào mỗi gói dữ liệu.
  • Người nhận trích xuất thông tin từ gói nhận được.
• Đặc điểm:
  • Dữ liệu có thể bị mất hoặc nhận không theo thứ tự.
  • Cung cấp truyền tải không tin cậy giữa client và server.

• TCP (Transmission Control Protocol):
  • Kết nối cần thiết: Client phải liên hệ với server, và server phải đang chạy.
• Cách thức hoạt động:
  • Server tạo socket để chờ kết nối từ client.
  • Client tạo socket TCP, chỉ định địa chỉ IP và số cổng của server.
  • Khi client kết nối, server tạo một socket mới để giao tiếp với client đó.
• Đặc điểm:
  • Cho phép server xử lý nhiều client cùng lúc.
  • Sử dụng số cổng nguồn để phân biệt các kết nối.