路由器的工作原理及数据是如何在路由器中通过

Posted 2023-05-09

参考技术A 对于一般人而言只要能使用路由器上网就可以了，但对于一个合格的网管来说，是必须要知道路由器的工作过程的，尤其是要知道数据是如何在路由器中通过的。

一、当数据经过路由器时，在原始套接口上可调用connect函数， connect函数仅设置目的地址。再重申一遍：端口号对原始套接口而言没有意义。对于输出而言，调用connect之后，由于目的地址已经指定，我们可以调用write或send，而不是sendto了。

二、普通输出通常通过sendto或sendmsg并指定目的IP地址来完成，如果套接口已经连接，也可以调用write、writev或send，如果IP_HDRINCL选项未设置，则内核写的数据起始地址是IP头部之后的第一个字节。
因为这种情况下，内核将构造IP头部，并将它安在来自进程数据之前。内核将IPv4头部的协议字段设置成用户在调用socket函数时所给的第三个参数。

三、如果IP_HDRINCL选项已设置，则内核写的数据其实地址是IP头部的第一个字节。用户所提供的数据必须包括IP头部。此时进程构造除了以下两项以外的整个IP头部，IPv4标示字段可以设为0，要求内核设置该值。而且仅当该字段为0时，内核才为其设置和IPv4头部校验和由内核来计算和存储。

四、如果创建原始套接口时指定了协议类型，即第三个参数protocol，那也并不是说只能发该类型的数据包。如，即使将protocol指定为IPPROTO_TCP，也可以发送用户自己组装的UDP报文，不过此时如果IP_HDRINCL选项未设置，那么内核将会在IP头的协议字段指明后面的报文为TCP报文(不过此时却为UDP报文)。
等数据包发送到对方TCP层，一般说来会因为找不到合适的TCP套接口接收该数据包而被丢弃。不过该包可以在目标主机的原始套接口上接收到。

五、如果IP_HDRINCL选项已设置，按照常规，应该组建自己的IP头，但是即使我们没有组建IP头，用sendto或sendmsg并指定目的IP地址来发送数据是照样可以完成的。但是这样的数据包在目标机上用原始套接口是接收不到的，因为在ip_rcv()中要对IP头进行验证，并且要分析校验和，所以该包会被丢弃，不过在链路层应该能够接收到该数据包。

六、如果设置了IP_HDRINCL选项，并且数据包超长，那么数据会被丢弃，并会返回出错码EMSGSIZE。如果未设置IP_HDRINCL选项，并且数据包超长，那么数据包会被分片，要想接收到原始套接口，首先要接收的数据包必须有一个完整的、正确的IP头，否则不能通过ip_rcv()中的包头检查和检验和验证。

七、在原始套接口接收的数据包过程中，内核会对接收的IP包进行校验和验证，但不会对IP包以后的任何字段进行检测和验证。如，我们创建原始套接口时，所指定的protocol参数为IPPROTO_TCP，内核也不会进行TCP校验和验证，而是直接把IP头中协议字段为TCP的所有数据包都复制一份，提交给该原始套接口。

八、用原始套接口接收到的TCP包都是进行了IP重组以后，TCP排序以前的报文。如果在创建原始套接口时，所指定的protocol参数不为零，(socket的第三个参数)，则接收到的数据报的协议字段应该与之匹配。
否则该数据报不传递给该套接口。如果此原始套接口上绑定了一个本地IP地址，那么接收到的数据报的目的IP地址应该与该绑定的IP地址相匹配，否则该数据包将不传递到该套接口。
如果此原始套接口通过connect指定了一个对方IP地址，那么接收到的数据包的源IP地址应与该以连接地址相匹配，否则该数据包不传递给该套接口。

原始套接口接收不到任何的ARP或RARP协议类型的套接口，因为net_rx_action()会把ARP或RARP协议类型的数据包传递给ARP的接收函数类处理，不会传递给IP层的接收函数ip_rcv()，因为有些ICMP类型的数据包在传递给原始套接口之前已经被系统所响应，并不再向上层传递。

如何在 Flutter (Dart) 中通过新路由获取子级 StreamProvider 数据

【中文标题】如何在 Flutter (Dart) 中通过新路由获取子级 StreamProvider 数据

【英文标题】：How to get StreamProvider data in children with new routes in Flutter (Dart)

【发布时间】：2021-02-26 19:29:33

【问题描述】：

我正在使用 StreamProvider 方法用某些数据包装我的小部件，例如来自 Firebase Auth 的 Auth（在我的应用程序中的任何地方都可以使用）。我想对 Firestore 值做同样的事情，但它似乎只工作一层。

我有一个数据库调用，一旦完成身份验证检查，就会找到员工档案。当我尝试使用 Provider.of(context) 从我的 Home() 小部件中获取员工时，效果很好：

这是我的包装小部件（这是我的主文件的主页：小部件）

class Wrapper extends StatelessWidget 
  @override
  Widget build(BuildContext context) 

    final user = Provider.of<User>(context);
    print(user.uid);

    // Return either home or authenticate widget
    if (user == null) 
      return Authenticate();
    
    else 
      return StreamProvider<Employee>.value(
        value: DatabaseService().linkedEmployee(user.uid),
        child: Home(),
      );
    
  

DatabaseService() 中的数据库服务函数：

// Get Linked Employee
  Stream<Employee> linkedEmployee(String uid) 
    return employeesCollection.where("linkedUser", isEqualTo: uid).snapshots().map(_linkedEmployeeFromSnapShot);
  
  
  Employee _linkedEmployeeFromSnapShot(QuerySnapshot snapshot) 
    final doc = snapshot.documents[0];
    return Employee(
        eId: doc.data["eId"],
        employeeCode: doc.data["employeeCode"],
        fName: doc.data["fName"],
        lName: doc.data["lName"],
        docId: doc.documentID
    );
  

我可以从树中任何位置的任何小部件访问Provider.of<User>(context)。那么为什么我不能为Provider.of<Employee>(context) 做同样的事情呢？

当我在 Home() 以外的任何小部件中尝试时，我得到了错误：

错误：在此车辆小部件上方找不到正确的提供程序

例如，在我的小部件车辆中：

class Vehicles extends StatelessWidget 
  @override
  Widget build(BuildContext context) 

    final user = Provider.of<User>(context);
    final employee = Provider.of<Employee>(context);
    ...

用户提供者工作正常，我可以打印出来，但员工提供者不工作。

这与上下文有关吗？谢谢，任何建议将不胜感激。

我如何使用带有此事件的凸起按钮从 Home() 导航到 Vehicles() 小部件：

onPressed: () 
  Navigator.push(
  context,
  MaterialPageRoute(builder: (context) => Vehicles())
   );
  ,

【参考方案1】：

这里有一个更解释的回复，因此我认为有些人会遇到这个问题，而且我也认为解决这个问题有点棘手，尤其是当您的 Firestore 中有规则要求用户被授权访问数据库时.

但通常，您希望将提供程序（您希望在所有应用程序周围访问）包装在 MaterialApp() 周围。

所以我给你看一个简单的例子让你更容易理解。

//The App() handles makes the providers globally accessible
class App extends StatelessWidget 
  @override
  Widget build(BuildContext context) 
    return FirebaseAuthProviderLayer(
      child: AuthorizedProviderLayer(
        authorizedChild: MatApp(child: StartSwitch()),
        unAuthorizedChild: MatApp(child: SignInScreen()),
      ),
    );
  


//The MaterialApp Wrapped so that it not has to be rewritten
class MatApp extends StatelessWidget 
  Widget child;

  MatApp(this.child);

  @override
  Widget build(BuildContext context) 
    return MaterialApp(
      title: 'App',
      home: child,
    );
  


class FirebaseAuthProviderLayer extends StatelessWidget 
  final Widget child;

  FirebaseAuthProviderLayer(this.child);

  @override
  Widget build(BuildContext context) 
    return StreamProvider<User>.value(
      value: FirebaseAuth.instance.authStateChanges(),
      child: child,
    );
  


//And the layer that decides either or not we should attach all the providers that requires the user to be authorized.
class AuthorizedProviderLayer extends StatelessWidget 
  Widget authorizedChild;
  Widget unAuthorizedChild;

  AuthorizedProviderLayer(this.unAuthorizedChild, this.authorizedChild);

  User user;
  final FirestoreService firestoreService =
      FirestoreService(); //The Service made to access Firestore

  @override
  Widget build(BuildContext context) 
    user = Provider.of<User>(context);
    if (user is User)
      return MultiProvider(
        providers: [
          StreamProvider<FirestoreUserData>.value(
            value: firestoreService.streamUser(),
          ),
          StreamProvider<AppSettings>.value(
            value: firestoreService.streamSettings(),
            initialData: null,
          )
        ],
        child: authorizedChild,
      );
    return unAuthorizedChild;
  

【讨论】：

嗨 Max，非常感谢您的详细回复，实际上我确实按照您在此处的推荐使用 MultiProvider 来完成这项工作，所以您的答案很准确，非常感谢。跨度>