Có rất nhiều giao thức tầng ứng dụng. Các tên HTTP, WebSocket, SMTP, POP3/IMAP, FTP, Telnet, SSH, RTP, DNS cũng thường xuất hiện cùng nhau.

Ping được thì TCP có chắc chắn kết nối được không? Tiểu G kết luận trước: Không phải.

Lúc này bạn có thể sẽ thắc mắc: rõ ràng Ping được, tại sao TCP lại không hoạt động? Nói chính xác hơn, Ping được chỉ cho biết đường đi của ICMP Echo có thể đi và về theo policy hiện tại, không có nghĩa là port TCP của mục tiêu chắc chắn có thể truy cập.

Sau khi nhập domain name vào thanh địa chỉ của trình duyệt, trước khi thực hiện HTTP request, trình duyệt thường phải phân giải DNS.

DNS giải quyết bài toán ánh xạ giữa domain name và địa chỉ IP. Thoạt nhìn, nó chỉ là “dịch domain name thành IP”, nhưng phía sau liên quan đến cả một hệ thống cơ chế gồm cache cục bộ, truy vấn đệ quy, truy vấn lặp, authoritative server, root server và chuyển đổi giữa UDP/TCP.

Nhiều người lần đầu học HTTPS sẽ lưu lại một ấn tượng khá đơn giản:

HTTPS = HTTP + encryption, encryption = RSA. Vì vậy, HTTPS = RSA encryption.

Cách hiểu này không phải tự nhiên mà có. Thời kỳ đầu, nhiều hệ thống HTTPS thực sự dùng nhiều cipher suite liên quan đến RSA, và nhiều tài liệu nhập môn cũng thích lấy RSA làm ví dụ.

Một host chỉ duy trì được tối đa 65535 TCP connection thôi sao? Tiểu G chốt trước: không phải.

Con số 65535 xuất phát từ phạm vi port. Các trường source port và destination port trong TCP header đều có độ dài 16 bit, có thể biểu diễn các giá trị 0~65535, tổng cộng 2^16 = 65536 giá trị. 65535 là port number lớn nhất, không phải giới hạn số connection.

Bài viết này được biên soạn và hoàn thiện từ bài Các phương thức tấn công TCP/IP thường gặp - Ghi chép Nuanlan - 2021.

TCP/IP protocol stack hướng tới khả năng liên thông, nhưng khi được thiết kế ban đầu, nhiều cơ chế chưa tính đến quy mô và cường độ tấn công ngày nay.

Trước đó đã nói TCP hướng theo byte stream, UDP hướng theo datagram. Điểm này trông giống một câu định nghĩa, nhưng nhiều vấn đề sticky packet, packet splitting thực ra đều bắt nguồn từ đây.

Trước hết, kết luận là: TCP chỉ đảm bảo các byte đến nơi một cách tin cậy, đúng thứ tự, không đảm bảo ranh giới message của application layer; UDP giữ lại ranh giới datagram mà application layer giao cho nó.

TCP three-way handshake và four-way teardown rất dễ bị học thuộc thành một sơ đồ: client gửi SYN, server trả SYN+ACK, cuối cùng gửi thêm ACK; khi đóng connection thì đi lại theo thứ tự FIN, ACK, FIN, ACK.

TCP thường được gọi là giao thức truyền tải tin cậy, nhưng “tin cậy” không phải một lời hứa trừu tượng, mà là kết quả phối hợp của một nhóm cơ chế cụ thể.

Mất packet thì phải retransmission, packet đến không đúng thứ tự thì phải sắp xếp lại, bên nhận xử lý không kịp thì cần flow control, network bị congestion thì phải chủ động giảm tốc. Chỉ khi xâu chuỗi các cơ chế này lại, bạn mới thực sự hiểu vì sao TCP có thể cung cấp truyền tải tin cậy trên nền mạng IP không tin cậy.

Bước cuối của TCP four-way handshake là sau khi bên chủ động đóng gửi ACK, bên đó không đóng ngay mà chuyển sang trạng thái TIME_WAIT, mặc định phải chờ 60 giây.

60 giây này thường bị hiểu nhầm: có người cho rằng đây là lãng phí tài nguyên, có người muốn dùng kernel parameter để cưỡng chế tắt, có người lại điều tra lẫn lộn CLOSE_WAIT và TIME_WAIT.