Máy tính kết nối với PLC và đèn liên kết vẫn sáng, nhưng việc đọc tham số thỉnh thoảng tạm dừng. Một lúc sau, quá trình này tiếp tục, dường như không mất dữ liệu. Có thể thiết bị không xử lý chậm: TCP có thể đang lấp một khoảng trống. TCP là cơ chế giao vận được nhiều máy tính giám sát, gateway và bộ điều khiển sử dụng. Cơ chế này hướng tới việc chuyển giao một luồng byte theo đúng thứ tự. Hướng dẫn này theo dõi các byte đó mà không dùng diễn giải toán học: bên nào lưu bản ghi, bên nào chờ và vì sao việc cuối cùng vẫn nhận được dữ liệu vẫn có thể ảnh hưởng đến chu kỳ sản xuất.
1. Mạng vận chuyển dữ liệu; các đầu cuối truyền lại dữ liệu
Máy tính giám sát chuyển dữ liệu cho bộ triển khai TCP của nó, sau đó qua giao diện mạng và các switch công nghiệp đến PLC. Switch thường chuyển tiếp khung Ethernet dựa trên địa chỉ Ethernet. Nó không thay mặt kết nối TCP đó xác nhận từng byte. Các đầu cuối truyền thông lưu giữ bản ghi truyền, xử lý xác nhận và quyết định khi nào truyền lại. Nếu gateway kết thúc một kết nối và khởi tạo kết nối khác, hãy phân tích riêng hai kết nối thay vì coi toàn bộ tuyến là một kênh không phân chia.
Hãy hình dung TCP như một bản thảo liên tục có các vị trí được đánh số. Tầng giao vận có thể chia bản thảo thành các gói có kích thước khác nhau, nhưng cuối cùng bên nhận phải nhận được nội dung theo đúng thứ tự. Phép so sánh này chỉ giải thích việc đánh số và khôi phục khoảng trống. TCP không hiểu bản thảo: nó không thể biết các byte biểu thị nhiệt độ, tệp tham số hay lệnh khởi động. Ứng dụng phải quyết định thông tin đó có hợp lệ hay không.
2. Số thứ tự và số xác nhận đếm byte, không đếm gói
Trong một ví dụ đơn giản, một kết nối đã thiết lập gửi ba phân đoạn dữ liệu chứa các byte 1001–1100, 1101–1200 và 1201–1300. Các số này chỉ mang tính minh họa; kết nối thực tế không có số thứ tự ban đầu cố định. SEQ xác định số thứ tự bắt đầu của dữ liệu trong một phân đoạn. ACK xác định byte tiếp theo mà bên nhận mong đợi trong luồng liên tục. Sau khi phân đoạn đầu tiên đến, xác nhận có thể trỏ đến 1101, xác nhận phần nội dung liên tục trước đó.
Nếu phân đoạn thứ hai bị thiếu nhưng phân đoạn thứ ba đến, bên nhận thường có thể lưu dữ liệu đến sau vào bộ đệm trong khi xác nhận tích lũy vẫn ở 1101. Nhìn thấy byte 1300 khác với việc có đủ tất cả các byte ở giữa. Xác nhận có thể tiến lên khi khoảng trống được lấp đầy. ACK không phải số thứ tự gói, vì vậy chỉ đếm các dòng trong bản ghi bắt gói không thể cho biết có bao nhiêu nội dung ứng dụng bị thiếu.
3. Xác nhận trùng lặp và bộ định thời cung cấp các dấu hiệu khác nhau
Bên gửi giữ lại dữ liệu chưa được xác nhận. Nếu dữ liệu đến sau tiếp tục được nhận, bên nhận có thể báo lặp lại cùng một số xác nhận, cho thấy có khoảng trống ở phía trước. Trong ví dụ truyền lại nhanh kiểu cổ điển, ba ACK trùng lặp kích hoạt việc truyền lại phân đoạn bị thiếu. Các cách triển khai hiện đại cũng có thể sử dụng phương pháp phát hiện mất dữ liệu khác. Không phải mọi thiết bị đều tuân theo chính xác một sơ đồ thời gian đơn giản hóa.
Nếu lưu lượng ít, có thể không có đủ dữ liệu đến sau để tạo ra các xác nhận lặp lại đó. Khi ấy, bộ định thời truyền lại có thể cung cấp cơ chế khôi phục. RTO, thời gian chờ truyền lại, là khoảng thời gian chờ xác nhận. Đầu cuối xem xét độ trễ khứ hồi và mức biến thiên của nó thay vì dùng một giá trị cố định cho mọi kết nối. Nếu bộ định thời hết hạn mà chưa có xác nhận cần thiết, đầu cuối sẽ truyền lại dữ liệu; việc liên tục không nhận được phản hồi thường làm kéo dài thời gian chờ. Không có giá trị mili giây cụ thể nào ở đây là cam kết về sản phẩm FCTEL.
4. Dữ liệu được khôi phục vẫn có thể gây ra khoảng tạm dừng dễ nhận thấy
Truyền lại cần thời gian. Bên nhận có thể chờ lấp đầy khoảng trống trước khi chuyển các byte liên tục tiếp theo cho ứng dụng. Dữ liệu đã đến giao diện mạng không nhất thiết cập nhật ngay lên màn hình. Đây là một hệ quả có thể xảy ra của cơ chế giao vận. Đèn liên kết sáng không có nghĩa là ứng dụng luôn cập nhật đúng hạn, và một lần tạm dừng không xác định được một cổng switch cụ thể là nguyên nhân.
TCP cũng kiểm soát lượng dữ liệu được gửi cùng lúc theo điều kiện mạng. Mất dữ liệu có thể được xem là tín hiệu tắc nghẽn, khiến bên gửi giảm hoạt động gửi. Điều này diễn ra trong giao thức tại đầu cuối; không có nghĩa là tốc độ cổng đã thương lượng tự động giảm xuống. Một kết nối có thể tạm thời chuyển giao ít dữ liệu hữu ích hơn trong khi liên kết vật lý vẫn báo tốc độ Gigabit. Cơ chế chuyển giao tin cậy cố gắng khôi phục dữ liệu bị thiếu, nhưng không cung cấp thời hạn điều khiển công nghiệp cố định.
5. Xác nhận TCP không phải thông báo hoàn tất tác vụ
ACK TCP xác nhận các byte tương ứng tại bên nhận TCP ở đầu đối diện. Nó không chứng minh rằng ứng dụng PLC đã chấp thuận một tham số, ghi tham số đó vào đích hay hoàn tất một thao tác của động cơ. Giao thức ứng dụng thường cung cấp phản hồi, mã ngoại lệ hoặc trạng thái hoàn tất riêng. Hãy ghi riêng xác nhận ở tầng giao vận, phản hồi giao thức và kết quả của thiết bị thay vì gộp các dấu thời gian của chúng thành một thông báo thành công.
Khi các byte chồng lặp được truyền lại trên cùng một kết nối, TCP sử dụng số thứ tự để nhận biết dữ liệu trùng lặp và thông thường không chuyển chúng cho ứng dụng như nội dung luồng mới. Một ứng dụng hết thời gian chờ rồi gửi lại lệnh đang tạo ra một yêu cầu ứng dụng khác. TCP không thể quyết định rằng hai yêu cầu có cùng ý nghĩa. Sau khi kết nối lại, hãy kiểm tra mã định danh yêu cầu, trạng thái thực thi và các quy tắc về yêu cầu trùng lặp do giao thức ứng dụng quy định. Lặp lại vô hạn các lệnh hành động không phải là chiến lược hợp lý để bảo đảm hoàn tất.
6. Chẩn đoán cả hai chiều và đối chiếu thời gian của ứng dụng
Ghi lại thời điểm tạm dừng, các đầu cuối, giao thức, lượng dữ liệu và thao tác. Sau đó kiểm tra bộ đếm lỗi và loại bỏ tại cổng, nhật ký kết nối và bản ghi bắt gói ở cả hai đầu. Việc gửi lại cùng một dải byte là dấu hiệu hữu ích. Đồng thời kiểm tra xem ACK có tiến lên không, dữ liệu có bị đảo thứ tự không và cửa sổ nhận được quảng bá có trở nên nhỏ hoặc bằng không không. Cửa sổ cho biết lượng dữ liệu mà bộ đệm nhận có thể tiếp nhận; điều này khác với việc cáp có được kết nối hay không.
Công cụ bắt gói đánh dấu một lần truyền lại bằng cách diễn giải các gói mà nó quan sát được. Nó không trực tiếp đo được một thành phần bị lỗi. Cổng phản chiếu quá tải, mất gói trong quá trình bắt gói hoặc bắt đầu bắt gói muộn có thể làm sai lệch phân tích. Cơ chế offload của giao diện mạng cũng có thể làm thay đổi cách phân đoạn hiển thị trong bản ghi bắt gói trên máy chủ. Hãy so sánh bản ghi từ cả hai phía để phân biệt dữ liệu chiều đi bị thiếu, xác nhận chiều về bị thiếu và các gói mà quá trình bắt gói đơn giản là không quan sát được.
Nếu lỗi kiểm tra khung tăng cùng thời điểm, hãy kiểm tra đầu nối, cáp, lớp chống nhiễu và nhiễu. Nếu số lần loại bỏ tăng theo các đợt lưu lượng bùng phát, hãy tìm hiểu lưu lượng cạnh tranh ở chiều ra và hoạt động của bộ đệm. Nếu chỉ các lần truyền dữ liệu lớn qua router hoặc đường hầm bị lỗi, hãy tìm hiểu thêm giới hạn kích thước trên đường truyền. Mỗi lần chỉ thay đổi một điều kiện và lưu giữ bằng chứng trước và sau thay đổi. Chỉ tăng thời gian chờ của ứng dụng có thể che giấu triệu chứng mà không loại bỏ độ trễ ở tầng giao vận.
Lưu lượng chiều về rất quan trọng: dữ liệu có thể đã đến trong khi xác nhận của nó bị mất trên đường về. Không có xác nhận đó, bên gửi có thể truyền lại và bên nhận nhận biết các byte lặp lại. Vì vậy, một lần truyền lặp lại không chứng minh rằng dữ liệu ban đầu chưa từng đến đích. Hãy vẽ riêng đường đi và đường về, đồng thời so sánh bản ghi của bên nhận. Nếu không, việc thay cáp bên cạnh bên gửi có thể bỏ sót đường về thực tế. Hãy kiểm tra cả hai chiều thay vì dùng một lần truyền một chiều để đại diện cho kết nối.
7. Xác minh nội dung chính xác và kết quả kịp thời, có thể sử dụng
Tài liệu switch công nghiệp có quản lý FCTEL là điểm khởi đầu để kiểm tra giao diện và chức năng quản lý. Hãy xác nhận model, tài liệu hướng dẫn và firmware thực tế cung cấp những bộ đếm và nhật ký nào. Bài viết này mô tả cơ chế hoạt động chung của TCP. Bài viết không khẳng định rằng switch xử lý TCP thay cho các đầu cuối hoặc cách triển khai giao thức của nhà cung cấp khác đại diện cho hiệu năng của một thiết bị FCTEL cụ thể.
Sau khi khôi phục, hãy xác minh nội dung tệp hoặc tham số, sau đó quan sát phân bố thời gian phản hồi và các ngoại lệ trong quá trình vận hành liên tục. Với yêu cầu hành động, cũng cần kiểm tra trạng thái hoàn tất và cách xử lý lệnh lặp lại. Sử dụng các thời hạn ứng dụng đã thống nhất cho địa điểm triển khai, phân biệt một lần tạm dừng đơn lẻ, tình trạng suy giảm dần và sự ngắt kết nối thực sự. Hãy nhớ ba điểm: TCP khôi phục khoảng trống byte, quá trình khôi phục cần thời gian, và việc nhận dữ liệu phải được kiểm tra riêng với việc hoàn tất tác vụ.
Báo cáo bảo trì cần nêu rõ triệu chứng và bằng chứng: dải byte nào được truyền lặp lại trong khoảng thời gian nào, phản hồi ứng dụng có bị chậm không và các bộ đếm cổng có thay đổi không. Chỉ ghi “sự cố mạng” là không đủ. Bản ghi cụ thể giúp các nhóm mạng, thiết bị và phần mềm phân tích cùng một sự kiện thay vì mỗi nhóm đều tuyên bố thiết bị của mình hoạt động bình thường. Nếu đồng hồ của các bản ghi bắt gói khác nhau, hãy xác định mối tương quan thời gian của chúng trước khi gộp hai sự kiện không liên quan thành một nguyên nhân giả định.
Tài liệu tham khảo kỹ thuật: RFC 9293: Số thứ tự và xác nhận TCP; RFC 6298: Bộ định thời truyền lại; RFC 5681: Truyền lại nhanh kiểu cổ điển và kiểm soát tắc nghẽn; Wireshark: Phân tích TCP; Wireshark: Offload và diễn giải bản ghi bắt gói. Tài liệu liên quan: Bài viết kỹ thuật và Tài liệu bộ chuyển mạch có quản lý FCTELE FCM-G24FG4 với 24 cổng Gigabit Ethernet + 4 cổng combo. Các hình minh họa nguyên gốc có hỗ trợ của AI thể hiện nguyên lý chung, không phải kết quả đo sản phẩm.
