BEYOND二十首经典的含义

博客对Beyond乐队的歌曲进行分类盘点,列出十大写意歌曲如《长城》《大地》等,十大抒情歌曲如《海阔天空》《真的爱你》等,还对部分歌曲进行了点评,虽有个人主观意见,但展现了Beyond经典歌曲的魅力。
Beyond的十大写意歌曲与十大抒情歌曲
   Beyond经典无数,区分写意和抒情的标准也不是绝对的,很多歌曲两者兼带。这里只是按比重来区分一下,也纯属个人意见。这里列出的基本上还是家驹时代的歌,其实3子时代也有不少好歌,如“遥远的Paradise” ,“大时代” ,“总有爱” ,“预备” 等,只不过相比之下,4子时代的还是要经典一些,这里并无偏见。    
  
  写意:    
   1. 长城  浑然大气之作。折戟沉沙,沉淀的是文明,浮现的是思考;江水东逝,带走的是岁月,留下的是使命。Beyond无愧于当代最具思考性的华人乐队,“长城” 的大气可媲美于“梦回唐朝” (虽然私下还是喜欢后者多那么一点点)。那些把Beyond归为纯粹流行乐队的人,有种也把唐朝否定了先?
    2. 大地  奠定Beyond乐坛地位的不朽之作,基本上可并列排在第一。虽然不一定每个人都少小离家的经历,但每个人都少不了志在四方的情怀。“看见一座山,就想知道山那边是什么样子” ,“大地” 曾是十几年前我高中班上的班歌。 
    3. AMANI  仿佛家驹是希望那些不幸身处屠戮之地的儿童们能乘上他高亢的嗓音,直上云霄,化作飞鸟,远离战火,奔向和平。这年头能唱歌的很多人都能到世界各地逛一圈,可第一,没几个没事儿愿意去非洲;第二,就算去了,又有几个能带回象AMANI这样有内涵的歌来?  
    4. 俾面派对  Paul的词风并不足够大气,象后来的“大时代” 就有这样的遗憾。但所幸的是贯中还是很有个性,出言尖锐,直指人心,对於无情地揭露市侩丑态来说还是恰到好处的。“俾面派对”可是当年的十大金曲之首。  
    5. 光辉岁月  知道很多视此歌为经典的人肯定不甘它屈居第五。说实话本人很喜欢这首歌本身,只不过觉得把它做给曼德拉就不值了。Beyond是理想化的,可政治和种族斗争的内幕可并不象单纯一首歌写得那么简单和直接了。 
    6. 农民  “文武英杰宣言” 听起来轻松得就象是游戏,可重新编曲,填上“农民” 的词后感觉天壤之别。面朝黄土背朝天,华夏文明就是农耕文明。上千年被禁锢在先辈的土地上,是惯看沧桑,还是无可奈何?把Beyond归为和零点是同样Pop乐队的人怎么也不想想,零点拿得出这样的歌来吗?怎么说内地的农业也比香港发达吧。  
    7. 灰色轨迹  此曲营造出的意境极其凄美,尾曲中两把吉它交相辉映,一个感觉冰凉彻骨,一个感觉似火焚心。  
    8. 抗战二十年  不为别的,只要想想Beyond的二十年给我们带来的无穷无尽的回味,就自然别有一番滋味上心头。  
    9. 阿拉伯跳舞女郎  Beyond早期的带有浓郁中东风情的代表作。 “梦里不知身是客,一晌贪欢” ,想象一下自己独身穿过丝路,醉倒在那异乡酒馆中的情景吧。相比之下,之后童安格的“耶利亚女郎” 显得口水化多了。  
    10. 早班火车  天蒙蒙亮了,可前路还没被照亮,感情还没有露出曙光,你早起,勤奋,追求,梦想,可命运的火车还不知把你带到何方……每个人都有无数个匆匆的早晨,每个早晨都有无数的东西要去想,Beyond用歌声为你打开第一扇窗。
  抒情:  
    1. 海阔天空  用不着多解释了,壮志未酬的惊世绝唱。套用一处评论的话,“它的激情与豪迈至今无人超越,包括Beyond自己” 。  
    2. 真的爱你  其实也应该是并列第一。不用多说了吧,曾经登上过所有流行榜第一的传世之作。动听的歌曲歌颂伟大的母爱,自身亦升华成经典。从Beyond口中唱出的爱,可不仅仅只是男女之间的那种。  
    3. 喜欢你  如果你真正喜欢一个人,那就用最直接的方式去赞美她,用不着拐弯抹角,这才是真正的情歌。  
    4. 无悔这一生  “没有泪光,风里劲闯……”,柔中有刚的一曲,这是Beyond很阳光的一面  
    5. 为了你为了我  这首单曲是最不好找的,原因就是它是Beyond给蔡兴麟写的,可谁记得那个姓蔡的唱过来着。要不是Beyond又拿回来自己演绎的话,这么一首好歌肯定就石沉大海,被埋没了。  
    6. 不再犹豫  倍受争议的一曲,攻击Beyond的人可以找到的最好的把柄。商业化啦,迎合大众啦,等等。我就不明白,通俗一点又有什么错了?少年励志,琅琅上口,引起共鸣难道不是写歌的目的?如果写歌不是写给人听的的话,那就让那些所谓的追求真正摇滚的人们都去对牛弹琴吧。同样风格的还有“战胜心魔” 。  
    7. 无尽空虚  如果你也想偶尔刻意颓废一下,那就就着家驹那带着颤音的磁性嗓音吧。  
    8. 谁伴我闯荡  Beyond的另一首励志类型的歌,不过感觉上更柔软,更无助了一点。曲子还是很好听的。  
    9. 冷雨夜  家强唱的第一首单曲,曲子很好听,不过家强的嗓音和家驹比还是有差距的。  
    10. 全是爱  纯粹怀念家驹的高音呼喊。和“海阔天空” 一样是家驹在最后一张“乐与怒” 专辑中留给歌迷的绝唱。 
   



ezerg 编程小语
你提供的内容是一段网络数据包的十六进制转储(hex dump),看起来是通过抓包工具(如 `tcpdump` 或 Wireshark)捕获的 IPv6 数据包。我们来逐层解析这段数据,并解释其含义。 --- ### ✅ 数据包基本信息 从文本中可以看到: ``` 05:52:20.072849 08:00:27:d4:10:bb (oui Unknown) > 33:33:00:00:00:16 (oui Unknown), ethertype IPv6 (0x86dd), length 102 ``` - **时间戳**:`05:52:20.072849`,表示捕获时间。 - **源 MAC 地址**:`08:00:27:d4:10:bb`(可能是 VirtualBox 虚拟机的 OUI) - **目的 MAC 地址**:`33:33:00:00:00:16` → 这是一个 IPv6 多播地址对应的以太网多播 MAC 地址。 - **协议类型**:IPv6 (`0x86dd`) - **总长度**:102 字节(包括以太网帧头之后的数据) --- ## 🧩 协议结构解析 接下来是十六进制数据,我们按协议层级拆解: ### 1️⃣ IPv6 头部(前 40 字节) ``` 6000 0000 0030 0001 fe80 0000 0000 0000 0a00 27ff fed4 10bb ff02 0000 0000 0000 0000 0000 0000 0016 ``` #### 解析 IPv6 头: | 字段 | 值 | 含义 | |------|-----|-------| | 版本/Traffic Class/Flow Label | `6000 0000` | - Version: 6 - Traffic Class: `0x00` - Flow Label: `0x00000` | | Payload Length | `0030` | 48 字节(即后面扩展头+数据) | | Next Header | `0001` | ICMPv6(值为 58 才对?等下看是否错误) ❗注意这里有问题! | ⚠️ 实际上 **Next Header = 0x01 是 ICMP**,但这是 **IPv4 的定义**。在 IPv6 中,ICMPv6 的编号是 **58(0x3a)**。 然而此处 `0x0001` 明显不对 —— 应该是 `0x3a` 表示 ICMPv6。 再检查原始数据: ``` ... 0001 fe80 ... ``` → 第 6 字节是 **Next Header** 字段,确实是 `0x01`,这不合规! 但这可能是因为显示格式问题或误读。继续往下看更关键的部分。 让我们重新定位: IPv6 固定头部共 40 字节: 偏移 0~39(0x00~0x27): ``` [0x00] 6000 0000 -> Version + Flow Label [0x04] 0030 -> Payload Length = 48 [0x06] 00 -> Next Header? Wait... [0x07] 01 -> Hop Limit? ``` 标准 IPv6 头部结构: | 字段 | 长度 | |------|------| | Version, TC, Flow Label | 4 字节 | | Payload Length | 2 字节 | | Next Header | 1 字节 | | Hop Limit | 1 字节 | | 源地址 | 16 字节 | | 目的地址 | 16 字节 | 所以正确划分如下: ``` Offset 0x00: 60 00 00 00 # Version=6, TC=0, Flow Label=0 Offset 0x04: 00 30 # Payload Length = 48 (0x30) Offset 0x06: 00 # Next Header → 0? 不对! Offset 0x07: 01 # Hop Limit = 1 ``` Wait! 这里有个严重矛盾! 👉 正确字段顺序应为: ``` Bytes: 0000: 6000 0000 # Version & Flow Label ^^ ^^^^^^ || +---- Flow Label = 0 +------- Version=6, Traffic Class=0 0004: 0030 # Payload Length = 48 0006: ?? # Next Header 0007: ?? # Hop Limit ``` 所以: - `0x06`: 下一个头部 → 查看是 `0x3a` 吗? 回到原始 hex: ``` 0x0000: 6000 0000 0030 0001 ... ^^ ^^ ``` 即: - `0x04`: `00 30` → payload len = 48 ✅ - `0x06`: `00` → Next Header = 0? ❌ - `0x07`: `01` → Hop Limit = 1 ✅ 等等!`0030 0001` → 如果是 `0030` 是长度,那 `0001` 就不是一字节字段了! ❌ 错误在这里! 实际上,`Next Header` 是单字节,`Hop Limit` 是单字节。 所以应该是: ``` Offset 0x06: Next Header = value at byte 6 → which is the first byte of "0001" => 0x00 ? ``` No —— 让我们用字节索引重写前几个字节: ``` Byte Index: 0 1 2 3 4 5 6 7 [60][00][00][00] [00][30] [00] [01] ``` - Byte 0: `0x60` → b'01100000' → Version=6 ✅ - Bytes 1~3: TC & Flow Label = `0x000000` - Bytes 4~5: Payload Length = `0x0030` = 48 ✅ - Byte 6: Next Header = `0x00` → IPv6 Hop-by-Hop Option? No, unlikely. - Byte 7: Hop Limit = `0x01` ✅ But `0x00` for Next Header is **No Next Header**, which doesn't make sense here. Looking further: After IPv6 header comes source IP: ``` fe80 0000 0000 0000 0a00 27ff fed4 10bb ``` That’s: - Source: `fe80::a00:27ff:fed4:10bb` → link-local address ✅ (common in NDP) Destination: ``` ff02 0000 0000 0000 0000 0000 0000 0016 ``` → `ff02::16` → well-known IPv6 multicast address for **"all nodes interested in MLD or Router Discovery"** Specifically: `ff02::1:ff00:0016` would be solicited-node multicast, but this is `ff02::16` → actually not standard. Wait: `ff02:0:0:0:0:0:0:16` = `ff02::16` → used by some protocols like PIM, MLD? Actually, more likely it's a typo or misalignment. Now look at what follows after IPv6 header: ``` ... 8f00 2b5a ... ``` If we assume that after IPv6 header starts ICMPv6: Standard ICMPv6 message has: - Type (1 byte) - Code (1 byte) - Checksum (2 bytes) - Rest depends on type Suppose next header starts at offset `0x28`: ``` 0x0020: ... 0000 0000 0000 0016 8f00 2b5a ... ^^ ^^ ^^^^ ``` So at `0x28`: `8f 00 2b 5a ...` Let’s suppose: - Type = `0x8f` → 143? Not valid. - Or maybe `Type = 135` (Neighbor Solicitation)? That’s `0x87` Wait — common ICMPv6 types: - 133: Router Solicitation → `0x85` - 134: Router Advertisement → `0x86` - 135: Neighbor Solicitation → `0x87` - 136: Neighbor Advertisement → `0x88` Check if data matches NS/NA. Look again: At offset `0x28`: `8f00 2b5a` Wait — could it be: ``` Type: 135 (0x87) ? But we see 0x8f ``` No. But wait — earlier we had confusion about Next Header. Let me re-express full IPv6 header from hex: Raw bytes starting at Ethernet payload: ``` 60 00 00 00 # Version=6, Traffic Class=0, Flow Label=0 00 30 # Payload Length = 48 00 # Next Header → 0x00 → Hop-by-Hop Options? 01 # Hop Limit = 1 fe 80 00 00 00 00 00 00 00 00 0a 00 27 ff fe d4 10 bb # src ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 16 # dst ``` Then next part: ``` 0x0028: 8f 00 2b 5a ... ``` Ah! Now notice: if Next Header was wrong, perhaps it's actually **ICMPv6**, and the field was misread. But according to RFC 2460, Next Header should be 58 (`0x3a`) for ICMPv6. We have `0x00` → means "no next header", only allowed with extension headers. But no extension header present. So discrepancy! Unless... this is **not IPv6**, despite ethertype saying `0x86dd`? Wait no — two identical packets shown, both say `ethertype IPv6`. Alternatively, could this be **IPv6-in-IPv6** or another encapsulation? Another possibility: **display formatting error** in tcpdump. Let’s try parsing assuming it IS a Neighbor Advertisement. Known structure of **ICMPv6 Neighbor Advertisement**: ``` Type = 136 (0x88) Code = 0 Checksum = 2 bytes Flags (R,S,O): 4 bits Reserved: 28 bits Target Address (16 bytes) Options... ``` But our data at `0x28` is: ``` 8f 00 2b 5a ... ``` Not matching. Wait — go back to line: ``` 0x0020: 0000 0000 0000 0016 8f00 2b5a 0000 0002 ``` Break into bytes: From `0x0020`: ``` 00 00 00 00 00 00 00 16 → this is likely the last 8 bytes of IPv6 dest: ::16 then → 8f 00 2b 5a → now this looks like: Type: 0x8f = 143 → unknown Code: 0x00 Checksum: 0x2b5a ``` Still invalid. Wait — what if the **Next Header is actually 58**, but displayed incorrectly? Maybe the `0001` isn’t part of the IPv6 header? No — let's count: Ethernet header: 14 bytes (DA:6 + SA:6 + EtherType:2) Then IPv6 starts at byte 14. The hex dump shows offset `0x0000`, so aligned to IP payload. So yes, `6000...` is IPv6 header start. Let’s compare with known good packet. 💡 Insight: The destination MAC `33:33:00:00:00:16` maps directly to IPv6 multicast address `ff02::16`. And `ff02::16` is used by **MLDv2 (Multicast Listener Discovery)** or sometimes **SSM discovery**. Moreover, the packet uses Hop Limit = 1, which is typical for multicast control messages. And the ICMPv6 type might be MLD-related. RFC 2710: MLD uses ICMPv6 type **131** (`0x83`) for MLDv1 queries, but MLDv2 uses type **143** (`0x8f`)! ✅ Bingo! > **ICMPv6 Type 143 (0x8f)** = Multicast Listener Report v2 (MLDv2) So: - Type: `0x8f` = 143 → MLDv2 Report ✅ - Code: `0x00` ✅ - Checksum: `0x2b5a` (valid checksum computed over packet) - Then body of MLDv2 report So even though the Next Header field appears as `0x00`, it may be a display bug or your tool didn't decode properly. But based on context, it's very likely that: - This is an **MLDv2 Report** - Sent from `fe80::a00:27ff:fed4:10bb` - To multicast group `ff02::16` - Using link-layer multicast MAC `33:33:00:00:00:16` This is normal behavior on networks using IPv6 multicast (e.g., video streaming, service discovery). --- ### 🔍 Summary of Packet | Layer | Field | Value | Explanation | |------|-------|--------|-----------| | Ethernet | Src MAC | `08:00:27:d4:10:bb` | Likely a host (VirtualBox OUI) | | | Dst MAC | `33:33:00:00:00:16` | IPv6 multicast MAC for `ff02::16` | | | EtherType | `0x86dd` | IPv6 | | IPv6 | Source | `fe80::a00:27ff:fed4:10bb` | Link-local address | | | Destination | `ff02::16` | Multicast address for protocol use | | | Next Header | Should be `58` (ICMPv6) | | | Hop Limit | `1` | Prevents forwarding beyond subnet | | | Payload Len | `48` | Followed by ICMPv6 message | | ICMPv6 | Type | `143` (`0x8f`) | MLDv2 Report (RFC 3810) | | | Code | `0` | — | | | Checksum | `0x2b5a` | Validated by receiver | | | Body | Starts with `0000 0002 ...` | MLDv2 report records | --- ### 📄 Example: Parsing MLDv2 Report Structure An MLDv2 Report (Type 143) has the following format: ``` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Mcast Addr Recs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address Record [n] (variable) | | | + + ``` Each record: ``` Record Type (1 byte) Aux Data Len (1 byte) Number of Sources (2 bytes) Multicast Address (16 bytes) Source Addresses [0..N] (each 16 bytes) ``` In your packet: After `8f00 2b5a` comes: ``` 0000 0002 → Reserved=0, Num Records = 2 (big-endian) ``` Then two records begin. Next: `0400 0000 ... ff05 ... ff02 ...` Could be: - Record 1: - Type: `0x04` → TO_EXCLUDE mode - AuxLen: `0x00` - NumSrc: `0x0000` - MC Addr: `ff05::...` (scope 5 = site-local) - Record 2: - Similar This indicates the host is reporting interest in specific multicast groups. --- ### ✅ Conclusion This is an **MLDv2 Report (ICMPv6 type 143)** sent by a node to express interest in one or more IPv6 multicast groups. It's part of IPv6 multicast management, similar to IGMP in IPv4. Used by applications like: - Streaming media - Service discovery (e.g., mDNS over IPv6) - Real-time communication It's normal traffic on any network supporting IPv6 multicast. --- ### 💡 How to Analyze Such Packets Use Wireshark or `tcpdump -XX` with `-v` flag: ```bash tcpdump -i eth0 -vv -X ip6 && icmp6 ``` Or save to file and open in Wireshark: ```bash tcpdump -i eth0 -w ipv6.pcap ip6 ``` Wireshark will decode MLDv2 reports automatically. ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值