现在每个直播的链接都要签名字段才可以校验成功，所以需要开始debug逻辑，研究一下这个加密的签名字段哪里来的，先找到这个发送请求的js代码在哪里：
找到发送websocket的地方了，看了一下_getSocketParams这就是获取请求参数的方法啊，进入看一下里面的逻辑是啥：
是不是已经看到了signature这个字段，就是这个参数，还需要研究一下他的生成逻辑：
我在这里做了一些注释，方便研究后续逻辑，我们这里看到了，l就是签名signature参数，所以搞出来l就可以了，但是l又依赖s和n，n是websocket_key很明显，那就继续研究s，但是s又依赖于t + a + r + o + ee.VERSION这五个，其中t + r + ee.VERSION = "1.0.14-beta.0"是明显的， 那就需要研究a + o是啥了，a是啥呢？看样子是固定的：
o是啥呢？
看一下q的逻辑就知道o是啥了：
对q的逻辑了做了一些注释：
看一下真实环境里面返回的q都包含哪些数据：
返回的o里面包含的还是挺多的：
{
"device_platform": "web",
"cookie_enabled": true,
"screen_width": 1512,
"screen_height": 982,
"browser_language": "zh-CN",
"browser_platform": "MacIntel",
"browser_name": "Mozilla",
"browser_version": "5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36",
"browser_online": true,
"tz_name": "Asia/Shanghai",
"cursor": "r-1_d-1_u-1_h-7382783779368457243_t-1718938366645",
"internal_ext": "internal_src:dim|wss_push_room_id:7382756219691223858|wss_push_did:7347516590731134502|first_req_ms:1718938366551|fetch_time:1718938366645|seq:1|wss_info:0-1718938366645-0-0|wrds_v:7382784052924778358",
"host": "https://live.douyin.com",
"aid": "6383",
"live_id": 1,
"did_rule": 3,
"endpoint": "live_pc",
"support_wrds": 1,
"user_unique_id": "7347516590731134502",
"im_path": "/webcast/im/fetch/",
"identity": "audience",
"need_persist_msg_count": "15",
"insert_task_id": "",
"live_reason": "",
"room_id": "7382756219691223858",
"heartbeatDuration": "0"
}然后我们再开一个直播间，对比一下两个直播间生成的这个对象有啥差别：
可以看出来不一样的地方有四个字段，比较重要的有room_id和internal_ext这两个，因为这里面都包含有room_id，这个room_id还是很重要的存在，所以我们可以想办法把这两个字段里面的room_id给替换掉是不是就可以呢？嗯，我们暂时就先使用这种方案来搞出来o吧
有了o，那我们开始下一步搞s吧，看一下返回s的函数内部实现：
还是挺复杂的啊，还是搞我们的对比大法吧，看一下两个直播间的s参数有啥不同：
我去，好像还是这几个参数不一样啊，那不是好办了，直接替换room_id，然后就可以得到新的s了啊，说干就干，试试再说。
重点来了，有了s + n，就可以看一下l的生成逻辑了，l的生成逻辑主要在B这个闭包函数里面，找到这个函数：
就可以看到代码位置在哪里了：
是的，把这里面的逻辑搞清楚不是就可以搞到signature这个签名了嘛，好了，好好研究去吧，同学们，下课
