DNS Response Message Format

Giới thiệu

Bài trước chúng ta đã được giới thiệu về định dạng của thông điệp truy vấn DNS. Chúng ta đã phân tích khá chi tiết và cho thấy cách 1 máy sử dụng cờ Flags/Parameters để lựa chọn những tùy chọn (Option) khác nhau.

Trong bài này, chúng ta sẽ xem và phân tích những đáp ứng nhận được từ những truy vấn ở bài trước. Những đáp ứng của 1 truy vấn, trong trường hợp của 1 truy vấn đệ quy, đến trực tiếp từ máy chủ DNS mà chúng ta đã gửi truy vấn và trong trường hợp của 1 truy vấn không đệ quy sẽ đến từ các máy chủ DNS gần đây nhất mà các máy khách liên hệ để có được thông tin cần thiết.

Bài này là sự tiếp nối của bài trước đó, vì vậy hãy chắc chắn rằng các bạn đã hiểu được những bài trước của loạt bài DNS này để khi đọc bài này chúng ta có thể hiểu được 1 cách sâu sắc.

Phân tích DNS - Server Response

Đây là câu trả lời (được tô màu xanh) của truy vấn trước đó gửi đến 1 máy chủ DNS ở Úc (139.130.4.4), là nơi tôi yêu cầu phân giải tên miền www.firewall.cx:

Có 1 chi tiết đáng chú ý là thời gian để truy vấn này trở lại với máy của tôi. Thời gian từ lúc mà máy của tôi gửi gói tin cho đến khi nhận được câu trả lời 0.991 giây.

Trong 1 thời gian ngắn mà gói tin di chuyển từ Hy Lạp đến Úc, truy cập máy chủ DNS và máy chủ DNS đó đã gửi các truy vấn của nó cho đến khi tìm được câu trả lời và sau đó tạo ra 1 đáp ứng DNS để gửi trở lại Hy Lạp (nơi mạng gia đình của tôi).

Có rất nhiều yếu tố góp phần nên phản ứng khá nhanh này. Giao thức vận chuyển UDP, là giao thức không yêu cầu quá trình bắt tay 3 bước; tải trọng của máy chủ DNS mà tôi đã gửi truy vấn; tải trọng của các máy chủ DNS khác mà nó đã gửi yêu cầu; tốc độ của tất cả các máy chủ và của chính mạng gia đình và tải trọng chung giữa các router mà gói tin đã phải di chuyển qua để đến được các địa điểm khác nhau.

DNS Query Message Format

Giới thiệu

Bài này chúng ta sẽ đi vào phân tích các gói dữ liệu DNS (DNS packet). Chúng ta sẽ được thấy cách mà các thông điệp DNS được định dạng nên cùng với các các tùy chọn (Option) và các biến chứa trong những thông điệp đó. Để hiểu 1 giao thức, bạn phải hiểu thông tin mà giao thức đó mang từ 1 máy đến máy khác.

Bởi vì các định dạng thông điệp DNS có thể khác nhau, tùy thuộc vào đó là truy vấn hay là câu trả lời, nên tôi sẽ chia bài phân tích này thành 2 phần. Phần 1 phân tích định dạng DNS của 1 truy vấn, nói cách khác là sẽ cho thấy gói dữ liệu trông như thế nào khi chúng ta yêu cầu 1 máy chủ DNS phân giải 1 tên miền. Phần 2 phân tích định dạng DNS của 1 câu trả lời, chính là trả lời của máy chủ DNS về truy vấn của chúng ta.

Phân tích DNS - Host Query

Như đã đề cập trong bài trước, 1 truy vấn DNS được tạo ra khi 1 máy cần phải phân giải 1 tên miền thành 1 địa chỉ IP. Kết quả này có được là do việc bạn nhập "www.firewall.cx" trong thanh địa chỉ ở trên trình duyệt web của bạn hoặc chỉ đơn giản là bằng cách chạy 1 chương trình sử dụng Internet và từ đó tạo ra các truy vấn DNS để có thể giao tiếp thành công với máy chủ cần thiết.

Bây giờ tôi sẽ đưa ra 1 ví dụ để các bạn có thể hiểu rõ hơn. Hãy thử xem 1 gói tin có chứa truy vấn DNS trông sẽ như thế nào khi đang được truyền trên mạng:

Đây là gói tin đã được chụp lại và chúng ta sẽ chuẩn bị phân tích nó. Để tạo ra gói tin này, tôi đã gõ "ping www.firewall.cx". Dòng lệnh tạo ra gói tin này, bắt nguồn từ mạng của tôi và điểm đến của nó là 1 name server có địa chỉ ở Úc. Chú ý là cổng đích của gói tin này được thiết lập là 53, chính là cổng mà DNS hoạt động, và giao thức được sử dụng cho truy vấn DNS đó là UDP.

DNS Queries & Resolution Process

Giới thiệu

Bài này sẽ giúp các bạn hiểu được các truy vấn DNS hoạt động trên Internet và mạng gia đình của bạn như thế nào. Có 2 cách sử dụng hệ thống tên miền để phân giải 1 host hoặc 1 tên miền sang 1 địa chỉ IP và chúng ta sẽ xem xét từng cách một.

Các loại truy vấn và cách giải quyết

Như đã đề cập trong phần giới thiệu, có 2 cách cho 1 client sử dụng hệ thống tên miền.

Cách thứ nhất, client liên hệ với các máy chủ tên (điều này tương đương với 1 truy vấn không đệ quy) cùng 1 lúc cho tới khi nó tìm thấy máy chủ có chứa những thông tin mà nó yêu cầu. Cách khác là yêu cầu hệ thống máy chủ tên thực hiện bản dịch đầy đủ (điều này tương đương với 1 truy vấn đệ quy), trong trường hợp này, client sẽ gửi truy vấn và nhận được phản hồi có chứa địa chỉ IP của tên miền đang tìm kiếm.

Thật sự rất thú vị khi tìm hiểu về cách mà truy vấn DNS hoạt động như thế nào. Trong khi phân tích những gói tin được gửi và nhận từ các máy chủ DNS, tôi sẽ chỉ cho bạn cách mà client lựa chọn phương pháp mà client muốn truy vấn của nó sẽ được giải quyết.

Ví dụ về DNS Resolution

Chúng ta hãy cùng xem ví dụ sau:

Khi ai đó muốn truy cập trang web của Cisco (www.cisco.com), họ sẽ dùng trình duyệt web và gõ "http://www.cisco.com" hoặc "www.cisco.com" và sau 1 vài giây, trang web sẽ được hiển thị. Nhưng những gì xảy ra đằng sau những thao tác đó không phải ai cũng biết. Đó là những gì mà chúng ta sẽ tìm hiểu ngay bây giờ.

The DNS Protocol

Giới thiệu

Bạn đã bao giờ tự hỏi DNS đến từ đâu? Đây sẽ là những bài mà tôi và bạn sẽ cùng tìm hiểu về giao thức này. Bản tóm lược ngắn gọn về lịch sử DNS cũng sẽ giúp bạn hiểu lý do tại sao các máy chủ DNS đang chạy chủ yếu trên các hệ thống Linux và UNIX. Sau đó chúng ta có thể thấy DNS làm việc ở những tầng nào trong mô hình OSI và ở cuối bài này, tôi và bạn sẽ cùng tìm hiểu các Domain (tên miền) và các máy chủ DNS có cấu trúc như thế nào và làm sao để chúng đảm bảo được thời gian hoạt động và hiệu quả.

Lịch sử

DNS được sử dụng trong những ngày đầu khi Internet chỉ là 1 mạng nhỏ được tạo ra bởi Bộ Quốc Phòng Mỹ cho các mục đích nghiên cứu. Do đó mạng chỉ cần 1 file HOSTS chứa tất cả các thông tin cần thiết về máy tính ở trong mạng và giúp các máy tính chuyển đổi được thông tin địa chỉ và tên mạng cho tất cả các máy tính trong mạng một cách dễ dàng. Và đó chính là bước khởi đầu của hệ thống tên miền gọi tắt là DNS (Domain Name System).

Nhưng khi mạng máy tính ngày càng phát triển thì việc quản lý thông tin chỉ dựa vào 1 file HOSTS là rất khó khăn và không khả thi. Vì thông tin bổ sung và sửa đổi vào file HOSTS ngày càng nhiều và nhất là khi hệ thống máy tính được phát triển dựa trên bộ giao thức TCP/IP dẫn đến sự phát triển tăng vọt của máy tính:

- Lưu lượng và trao đổi trên mạng tăng lên.

- Tên miền trên mạng và địa chỉ ngày càng nhiều.

- Mật độ máy tính ngày càng cao do đó đảm bảo phát triển ngày càng khó khăn.

Đến năm 1984, Paul Mockpetris thuộc viện USC's Information Sciences Institute phát triển 1 hệ thống quản lý tên miền mới gọi là DNS và ngày nay nó ngày càng được phát triển và hiệu chỉnh bổ sung tính năng để đảm bảo yêu cầu ngày càng cao của hệ thống.

TCP Data

Giới thiệu

Cuối cùng, chúng ta đã đi đến bài cuối trong loạt bài phân tích về giao thức vận chuyển TCP. Bài này để dành riêng cho phần dữ liệu nằm tiếp sau TCP Header.

The Data

Chúng ta hãy cùng xem sơ đồ dưới đây:

Khi gói tin trên đến với người nhận, 1 quá trình mở gói là cần thiết để loại bỏ các phần được đóng gói thêm vào khi đi qua từng lớp của mô hình OSI. Sau đó, phần dữ liệu sẽ được đưa cho ứng dụng đang chờ đợi nó. Như vậy, khi gói tin được nhận đầy đủ bởi card mạng, nó được trao cho lớp 2 (Data Link), sau khi thực hiện kiểm tra lỗi ở trên gói tin, nó sẽ loại bỏ các thành phần liên quan đến lớp 2 (Data Link), có nghĩa là các khối màu vàng sẽ được loại bỏ.

Phần còn lại đó là IP Header, TCP Header, và dữ liệu, có thể gọi 3 phần đó là 1 IP Datagram, sẽ được đưa qua lớp 3 của mô hình OSI (Network) nơi các kiểm tra khác sẽ được thực hiện và nếu không phát hiện ra lỗi, IP Header sẽ bị tước bỏ và phần còn lại (bây giờ gọi là 1 Segment) sẽ được đưa lên lớp thứ 4 của mô hình OSI.

Giao thức TCP sẽ chấp nhận Segment và thực hiện kiểm tra lỗi trên Segment này. Giả sử không tìm thấy lỗi, thì TCP Header sẽ được gỡ bỏ và sẽ được đưa lên các lớp trên để đến với các ứng dụng đang chờ nó.

Tổng kết

Cuối cùng thì loạt bài về phân tích giao thức TCP đã xong. Sau khi đọc tất cả những bài này, tôi chắc chắn bạn sẽ có 1 sự hiểu biết tốt hơn về mục đích của giao thức TCP và quá trình diễn ra nó, và bạn có thể thực sự đánh gia cao chức năng của giao thức này.

Lược dịch từ bài gốc: Click Here

Analysing TCP Header Options

Giới thiệu

TCP Options (MSS, Window Scaling, Selective Acknowledgements, Time Stamps, Nop) có vị trí nằm ở cuối TCP Header.

Truyền thông dữ liệu càng ngày càng trở nên phức tạp hơn, ít chấp nhận sai sót và độ trễ, rõ ràng là các tính năng mới này đã được tích hợp cho TCP transport để giúp khắc phục nhiều vấn đề.

Ví dụ, Window Scaling, đã được đề cập đến ở bài trước và được giới thiệu ở đây, có thể sử dụng trường TCP Options bởi vì trường Window nguyên thủy của nó chỉ dài có 16 bits, cho phép một số thập phân tối đa là 65.535. Rõ ràng đây là con số quá nhỏ so với việc chúng ta muốn biểu thị giá trị 'Window Size' sử dụng những con số trong phạm vi kích thước hàng ngàn đến 1 triệu như 400.000 hay 950.000.

Trước khi đi phân tích chi tiết, chúng ta hãy xem qua trường TCP Options ở dưới hình sau:

Nằm ở cuối Header và ngay trước phần dữ liệu, nó cho phép chúng ta sử dụng những cải tiến mới được khuyến nghị bởi các kỹ sư đã giúp thiết kế nên các giao thức mà chúng ta đang sử dụng trong truyền thông dữ liệu ngày nay.

Bảo mật cá nhân - Sử dụng máy công cộng - Phần 2

Trong bài trước, ba thủ thuật đơn giản đã được giới thiệu nhằm giảm thiểu hiểm hoạ "mất mật khẩu" khi dùng máy công cộng. Phần thứ nhì đi sâu vào việc chuẩn bị một biện pháp khác có khả năng giảm thiểu hiểm hoạ bị mất mật khẩu ở mức độ tốt hơn. Tuy nhiên, nó đòi hỏi một quy trình chuẩn bị khá tỉ mỉ.

Tạo và sử dụng USB key có chứa phần mềm quản lý mật khẩu:

Đây có lẽ là biện pháp an toàn nhất khi sử dụng máy tính công cộng để đăng nhập nếu máy tính công cộng ấy cho phép gắn USB key vào máy. USB key là một thiết bị nhỏ gọn, khá rẻ tiền và thông dụng:

Bạn có thể mua một USB key ở bất cứ một tiệm bán đồ máy tính nào với dung lượng nhỏ (vì không cần dung lượng lớn). Một USB key chừng 64Mb là thừa để dùng rồi. Quy trình chuẩn bị này cần thực hiện trên một máy SẠCH, có nghĩa là bạn tin tưởng máy ấy không có mã độc.

Bảo mật cá nhân - Sử dụng máy công cộng - Phần 1

Vài năm gần đây, Internet và máy tính trở thành một phần của mọi sinh hoạt hàng ngày, từ chuyên gia cho đến các cháu học sinh từ các bà nội trợ đến các ông bà cụ. Không may, tình trạng "mất mật khẩu", "bị đánh cắp mật khẩu", "mất tài khoản" trở thành chuyện bình thường đến mức đáng sợ. Tuy vậy, nếu trang bị một số kiến thức căn bản và sự cẩn thận đúng mức thì có thể giảm thiểu phần lớn tình trạng "bị mất cắp". Bài viết này tập trung vào tình trạng bảo mật của máy tính và người dùng Internet ở Việt Nam cho người dùng sử dụng máy trên hệ điều hành Windows.

1. Thực trạng:

Tình trạng sử dụng máy công cộng như ở Internet Cafe, ở thư viện, ở trường học, ở các phòng máy của cơ quan, ở các dịch vụ, các trung tâm huấn nghệ...v.v.. là tình trạng rất chung và rất phổ biến. Rất nhiều người tin rằng "máy nào cũng như máy nào" nhưng thực tế, chẳng có gì bảo đảm tính bảo mật và an toàn khi sử dụng chúng.

Theo điều tra tổng quát (và khá giới hạn) của nhóm HVAOnline năm 2011, cứ trong 10 dịch vụ Internet Cafe ở Việt Nam thì có 9 dịch vụ bị dính mã độc mà quản lý của dịch vụ không hề biết (hoặc biết nhưng không quan tâm). Những máy tính ở các dịch vụ ấy được "sao" từ các bản "gốc". Không may, chính những bản "gốc" ấy có vô số virus và mã độc. Chương trình chống virus trên các bản "gốc" ấy thường quá cũ, không được cập nhật. Ngay cả trong một số trường đại học chuyên ngành CNTT cũng có những hệ thống máy sử dụng các software bị cài mã độc nhưng các quản lý viên không hề biết.

Một quốc gia vừa mở cửa ra với Internet, với cơ sở hạ tầng khá hạn chế và bé nhỏ so với các nước đã và đang phát triển như Việt Nam lại lọt vào danh sách top 20 quốc gia có nhiều virus cho mục đích tàn phá [1] là điều đáng lo ngại và bởi thế, chính người dùng cần cẩn thận hơn.

TCP Window Size, Checksum & Urgent Pointer

Giới thiệu

Bài này tôi sẽ giới thiệu một vài trường rất thú vị được sử dụng trong giao thức vận chuyển TCP. Chúng ta có thể thấy được làm thế nào để TCP giúp điều khiển dữ liệu được truyền đi trên mỗi Segment, đảm bảo không có lỗi trên từng Segment và cuối cùng, cắm cờ "khẩn cấp" cho dữ liệu của chúng ta để đảm bảo nó có được quyền ưu tiên khi đến được với người nhận.

Các trường mà chúng ta đang chuẩn bị phân tích ở đây chiếm tổng cộng khoảng 6 bytes trong TCP Header.

Những giá trị này, như hầu hết các trường trong Header của giao thức, đều giữ nguyên kích thước bất kể dữ liệu của ứng dụng có lớn như nào đi chăng nữa.

TCP Flag Options

Giới thiệu

Như chúng ta đã thấy ở những bài trước, 1 TCP Segment mang theo dữ liệu trong khi những cái khác chỉ đơn giản là báo nhận cho dữ liệu nhận được trước đó. Quá trình bắt tay 3 bước sử dụng SYN và ACK có sẵn trong TCP giúp hoàn thiện kết nối trước khi dữ liệu được truyền.

Mỗi TCP Segment đều có mục đích và điều này được xác định với sự trợ giúp của TCP Flag Options, cho phép bên gửi hoặc bên nhận chỉ ra cờ nên được sử dụng để các Segment xử lý 1 cách chính xác ở phía bên kia. Chúng ta hãy nhìn vào hình sau và cùng phân tích:

Bạn có thể thấy 2 cờ được sử dụng trong bắt tay 3 bước và truyền dữ liệu là SYN và ACK.

Với tất cả các cờ, giá trị bằng '1' được hiểu là cờ đấy đang được bật. Ví dụ trong hình chỉ có cờ SYN được bật, và chúng ta dựa vào đó đoán được đây là Segment đầu tiên của 1 kết nối TCP mới.

Mỗi cờ có độ dài 1 bit và có 6 cờ tất cả nên tổng cộng TCP Flags có độ dài 6 bits.

Bạn có lẽ cũng đồng ý với tôi rằng 3 cờ phổ biến nhất hay ít nhất mà chúng ta có nghe nói tới là cờ SYN, cờ ACK và cờ FIN lần lượt dùng để thiết lập kết nối, báo nhận thành công và kết thúc kết nối. Các cờ còn lại ít được biết đến nhưng nó có vai trò rất quan trọng. Chúng ta sẽ đi tìm hiểu tất cả 6 cờ này ngay bây giờ.

Người Việt trẻ tự đốt đuốc mà đi

1. Thời gian gần đây, chúng tôi hay có những trao đổi về tương lai của Việt Nam trong cơn gian khó: Trong đất liền thì lạm phát cao, kinh tế khó khăn, sức sản xuất giảm, doanh nghiệp phá sản hàng loạt. Ngoài biển Đông thì Trung Quốc liên tục gây căng thẳng, gia tăng tranh chấp không chỉ với Việt Nam mà còn cả khu vực. Nhìn xa hơn sang các nước Âu – Mỹ, tình hình cũng không sáng sủa hơn bao nhiêu. Châu Âu vẫn ngập trong khủng hoảng. Một số nước nếu chỉ năm ngoái thôi còn được coi là vững vàng, như Pháp chẳng hạn, thì sang năm nay, đã bị nhiều chuyên gia coi là một “quả bom hẹn giờ” mới.

Trước tình hình đó, nhiều người đã rất bi quan. Nhiều lúc chúng tôi có cảm giác, sự bi quan chán nản đã rút hết sinh khí của ngay cả những người được coi là từng trải và vững vàng nhất. Nhưng với riêng tôi, cảm thức bi quan chưa bao giờ là chủ đạo. Lý do: Thay vì nhìn mãi vào bức tranh màu xám, tôi nhìn vào những người Việt trẻ.

Tôi tin vào sức trẻ. Tôi tin đó là tài sản lớn nhất của dân tộc. Và tôi tin, chính tuổi trẻ chứ không phải các lý thuyết kinh tế xã hội kinh điển và nhiều tranh cãi, hay những lý tưởng khuôn sáo đã không còn sức sống, sẽ là cứu tinh của đất nước.

Tôi đi tìm tương lai của đất nước trên khuôn mặt những người Việt trẻ.

TCP Header Lenght Analysis

Giới thiệu

Trường tiếp theo mà tôi muốn giới thiệu chính là TCP Header Length. Thật sự không có nhiều vấn đề để nói về Header Length ngoài việc giải thích nó đại diện cho cái gì và làm thế nào để giải thích được giá trị của nó. Nhưng thực sự trường này cũng là 1 trường rất quan trọng và bạn sẽ thấy được điều đó.

Bạn cũng có thể thấy Header Length cũng giống như trường Data Offset trong Packet Sniffer hay Application (là 1 cái tên khác nhưng thực chất cũng chính là Header Length).

Phân tích Header Length

Nếu bạn đã đọc bất kì 1 cuốn sách nào về Networking có nói về TCP Header, bạn hầu như sẽ tìm thấy mô tả cho trường này như sau: "Một số nguyên xác định độ dài của Segment Header là bội số của 32 bits". Nhưng khi nhìn vào gói tin, thì ta sẽ phải băn khoăn suy nghĩ điều đó chính xác muốn nói về cái gì?

Tôi sẽ giải thích cho các bạn hiểu rõ hơn theo từng bước một.

TCP Sequence & Acknowledgement Numbers

Giới thiệu

Bài viết này sẽ đi sâu vào Sequence Number và Acknowledgement Number. Sự tồn tại của chúng có liên quan đến 1 thực tế rằng Internet và hầu hết các mạng nói chung đều là mạng chuyển mạch gói và bởi vì chúng ta gần như luôn nhận và gửi dữ liệu có kích thước lớn hơn so với MTU (đơn vị truyền dẫn tối đa) là 1500 trên hầu hết các mạng ngày nay.

Hãy thử nhìn vào các trường mà chúng ta chuẩn bị phân tích:

Chúng ta sẽ giải thích những con số này tăng bằng cách nào và chúng có ý nghĩa gì, làm thế nào để các hệ điều hành khác nhau có thể xử lý chúng bằng những cách khác nhau và cuối cùng, vì sao những con số này có thể trở thành mối nguy hiểm an ninh cho những người yêu cầu 1 mạng lưới vững mạnh và an toàn.

TCP Source & Destination Port Numbers

Phần này chúng ta sẽ nói về 1 trong các trường của TCP Header, các số hiệu của cổng nguồn và cổng đích. Các trường này được sử dụng để xác định các ứng dụng hoặc dịch vụ được cung cấp trên máy trạm hoặc máy chủ từ xa. Tôi sẽ lần lượt nói về tầm quan trọng và chức năng của các cổng nguồn và cổng đích của TCP.

Bạn sẽ hiểu được tầm quan trọng của cổng và cách sử dụng chúng để thu thập thông tin trên hệ thống từ xa được coi là mục tiêu để tấn công. Ở đây tôi sẽ giới thiệu các cổng giao tiếp từ cơ bản đến nâng cao với các ví dụ chi tiết. Bây giờ chúng ta sẽ bắt đầu với một số vấn đề cơ bản.

Khi 1 máy cần tạo ra yêu cầu hoặc cần gửi dữ liệu, nó đòi hỏi một số thông tin:

1. Địa chỉ IP của các máy chủ mà nó muốn gửi dữ liệu hoặc gửi yêu cầu.

2. Số hiệu cổng mà dữ liệu hoặc yêu cầu sẽ được gửi đến máy chủ từ xa đó. Trong trường hợp gửi 1 yêu cầu, nó cho phép người gửi xác định dịch vụ mà nó có ý định sử dụng.

In-depth TCP Header Analysis - Introduction

Tiếp theo tôi sẽ giới thiệu về việc phân tích TCP Header. Để dễ hiểu tôi sẽ chia thành 7 bài, mỗi bài 1 vấn đề và sử dụng những mô hình chi tiết, dễ hiểu để bạn có thể nắm được dễ dàng hơn.

Thứ tự các bài như sau:

Section 1: Source & Destination Port Numbers

Section 2: Sequence & Acknowledgement Numbers

Section 3: Header Length

Section 4: TCP Flag Options

Section 5: Window Size, Checksum & Urgent Pointer

Section 6: TCP Options

Section 7: TCP Data

Bài tiếp theo: TCP Source & Destination Port Numbers

The TCP Header/Segment

Giới thiệu

Bài này sẽ giới thiệu về TCP Header và TCP Segment. Chúng ta sẽ biết được TCP Header và TCP Segment nằm ở đâu trong 1 khung Ethernet và có 1 cái nhìn tổng quan về các tùy chọn (option) sẵn có trong TCP Header.

TCP Header và TCP Segment

Đơn vị truyền dữ liệu được sử dụng trong TCP được gọi là TCP Segment.

Nhìn vào mô hình trên ta có thể thấy TCP Segment = TCP Header + Data (dữ liệu thuộc về các tầng trên: 5,6,7).

Nội dung dữ liệu có thể là 1 phần của việc truyền file, hoặc phản hồi từ 1 http request, thực tế là chúng ta không thực sự quan tâm đến nội dung dữ liệu, nhưng trong thực tế nó là 1 phần của TCP Segment.

Quick Overview Of TCP

Như đã đề cập ở bài trước, TCP là 1 trong 2 giao thức nằm ở tầng vận chuyển và được sử dụng để truyền dữ liệu từ 1 host sang host khác. Vậy điều gì khiến cho TCP trở thành 1 cách thức phổ biến trong việc gửi và nhận dữ liệu như thế? Không giống UDP, TCP sẽ kiểm tra lỗi trong mỗi packet (gói tin) mà nó nhận được để tránh việc bị hỏng dữ liệu.

Một vài giao thức sử dụng TCP như là: FTP, Telnet, HTTP, HTTPS, DNS, SMTP và POP3. Bây giờ chúng ta sẽ có cái nhìn sâu hơn về những đặc điểm chính của giao thức tuyệt vời này.

Các đặc điểm chính

Sau đây là những đặc điểm chính của TCP mà chúng ta sẽ đi vào phân tích:

- Vận chuyển đáng tin cậy (Reliable Transport).

- Hướng kết nối (Connection-Oriented).

- Điều khiển luồng (Flow Control).

- Windowing.

- Acknowledgments.

- Nhiều chi phí hơn.

TCP, A Transport Protocol

Giới thiệu

Việc hiểu biết mỗi giao thức được xếp đặt vào trong mô hình OSI như thế nào là một điều cần thiết cho các kỹ sư mạng máy tính. Ở đây tôi sẽ phân tích về việc TCP được xếp vào loại "giao thức vận chuyển" như thế nào và điều gì mình có thể thấy được ở giao thức này.

Việc sắp xếp TCP vào mô hình OSI

Như chúng ta đã biết, mỗi giao thức đều có chỗ của nó trong mô hình OSI (mỗi giao thức hoạt động ở 1 layer cụ thể). Mô hình OSI là 1 biểu thị tính phức tạp và độ thông minh của giao thức. Theo quy tắc tổng quát, càng lên tầng cao trong mô hình OSI, thì giao thức ở tầng đó càng trở nên thông minh. Việc đặt vị trí của tầng cũng phản ánh mức độ làm việc nhiều của CPU, trong khi đó các tầng thấp hơn của mô hình OSI thì hoàn toàn ngược lại, nghĩa là, mức độ làm việc của CPU ít hơn và bớt thông minh hơn.

TCP được đặt ở lớp thứ 4 của mô hình OSI, mà người ta còn gọi là tầng vận chuyển. Tầng vận chuyển chịu trách nhiệm thiết lập phiên kết nối, chuyển dữ liệu và phân nhỏ các kết nối ảo.

Với ý nghĩ này, bạn sẽ mong đợi bất cứ giao thức nào nằm trong tầng vận chuyển phải thực hiện một vài tính năng và đặc tính cho phép nó hỗ trợ những chức năng mà tầng vận chuyển quy định.

Vì thế sau khi phân tích TCP, bạn sẽ chắc chắn rằng TCP phải được xếp vào tầng vận chuyển.

Đàn ông - Nếu đã 20, nếu chưa 25

Nếu bạn là đàn ông, nếu bạn đã hai mươi, nhưng bạn chưa hai lăm tuổi, bạn buộc phải tìm được một thứ gì đó ngoài tình yêu, giúp đôi chân bạn đứng vững vàng trong cuộc đời này. Bạn phải bắt đầu nghĩ cách để kiếm đủ và sống được.

Tôi chưa từng bao giờ nghĩ bằng cấp là thứ quan trọng, thiên tài với danh nhân đâu phải từ lò luyện và trường lớp mà ra. Nhưng nếu bạn không học tới nơi tới chốn, thì dù có đi làm cửu vạn, ngay cả bao cát cũng sợ rằng chẳng biết cách mà vác.

Bạn buộc phải làm cho những suy nghĩ văn vẻ và cảm xúc màu mè thị dân của mình dần trở thành lối tư duy sáng sủa, rõ ràng và những ngôn từ giản tiện ngắn gọn. Bởi những thứ màu mè và bồng bột sẽ không thể tồn tại lâu. Bạn phải biết rằng, những sự thích thú khi khi đọc văn hay, nghe lời bay bướm mang lại sẽ chẳng mấy giá trị, trong khi thứ quan trọng nhất lại nằm ở trí tuệ, tinh thần, tâm hồn, nội dung, tư duy của bạn.

Là đàn ông, làm ơn đừng đọc văn của những nhà văn nữ cùng thời với bạn.

Là đàn ông, làm ơn đừng trách người khác, đừng nhỏ nhặt, làm ra vẻ đáng thương.

Làm ơn đừng nghĩ đến cái gì là viết về cái đó.

Và chớ tiếc rẻ đôi chút cảm động bé nhỏ, đôi chút thương xót nhỏ nhoi.