单向与双向的对比

1.一对一单向VS双向

-------------------------------单向---------------------------------------------

  person与address的一对一单向关系:

  在address中没有特殊的注解。

  在Person中对应到数据库里面就有一个指向Address的外键.我们也可以增加注释指定外键的列的名字,如下:

@OneToOne(cascade=CascadeType.ALL,optional=true) 
@JoinColumn(name="addressID")//注释本表中指向另一个表的外键。
    public Address getAddress() { 
        return address; 
    } 

 

------------------------------- 双向--------------------------------------------

person和IDCard的一对一双向关系

  person中

@OneToOne(cascade={CascadeType.ALL},optional=true)
    public IDCard getIdCard() {
        return idCard;
    }

IDCard中:

@OneToOne(cascade=CascadeType.ALL,mappedBy="idCard",optional=false)
    public Person getPerson() {
        return person;
    }

其中person为主控方,关系的维护者,它的表里有指向IDCard的外键。

--------------------------------------------------------------------------------------------------------------------------------------

2.一对多单向VS双向

-------------------------单向-----------------------------------------

person和phone的一对多单向关系:

phone中没有特别的注释。

person中:

@OneToMany(cascade=CascadeType.ALL)
@JoinColumn(name="personID")//注释的是另一个表指向本表的外键。
public List<Phone> getPhones() {
      return phones;
    }

-------------------------双向-----------------------------------------

person和car的一对多双向关系:

person中:

@OneToMany(cascade=CascadeType.ALL,mappedBy="person")
    public List<Car> getCars() {
        return cars;
    }

car中:

@ManyToOne(cascade=CascadeType.ALL,optional=false) 
    @JoinColumn(name="personID") 
public Person getPerson() { 
return person; 
    } 

----------------------------------------------------------------------------------------------------------------------------------------

3.多对多单向VS双向

------------------------单向---------------------------------------

person和country的多对一单向关系:

country中无特别的注解。

而person注解如下:

@ManyToOne
@JoinColumn(name="countryID")
    public Country getCountry() {
        return country;
    }

------------------------双向----------------------------------------

在person中

@ManyToMany(cascade = CascadeType.ALL)
    @JoinTable(name = "PersonANDFlight",         
         joinColumns = {@JoinColumn(name = "personID")},         
         inverseJoinColumns = {@JoinColumn(name = "flightID")})
    public List<Flight> getFlights() {
        return flights;
    }

在fight中:

@ManyToMany(mappedBy="flights")
    public List<Person> getPersons() {
        return persons;
    }

 

 

--------------------------------------------------------------------

区别:

1.双向在一实体中多了mappedBy,明确了主控方拥有外键

2.JoinColumn一般在主控方里面设置。一对多单向例外,JoinColumn在被控方即一方中声明。

3.一对多,多对一,多对多中多的一方为主控方,关系的维护者,拥有外键。

4.双向的一对多关系和一对一关系中的mappedBy可以避免生成中间表。

5.JoinColumn在一对多单向关系里面,如果你不加@JoinColumn(name="personID")这个注释的话,

   那么JBOSS就会自动帮你生成一张中间表。

  JoinColumn在多对一单向关系里面,在这里如果我们去掉@JoinColumn的话,

  那么一样会在Person表里面生成一列指向Country的外键,不会产生中间表。

转载于:https://www.cnblogs.com/cxccbv/archive/2009/01/22/1380047.html

<think>好的,用户想了解单向SSL双向SSL的区别。我需要先回忆一下相关知识,确保信息准确。首先,SSL/TLS是用于加密通信的协议,现在应该叫TLS更准确,但大家还是习惯说SSL。 单向SSL,也就是通常说的SSL,服务器有证书,客户端验证服务器。客户端确认自己连的是正确的服务器,但服务器不验证客户端。比如访问HTTPS网站,浏览器检查网站的证书是否可信,而网站不验证用户的证书,因为用户通常没有证书。这种模式常见于大多数网站,用户用密码等认证,而不是证书。 然后是双向SSL,也就是双向认证。这里服务器客户端都有证书,互相验证。服务器要验证客户端的证书,确保客户端是合法的,客户端也要验证服务器的证书。这种场景用在安全性要求更高的地方,比如银行内部系统或者企业之间的API通信。每个客户端都需要预先分配证书,可能增加管理成本,但更安全。 需要区分清楚两者在验证流程上的不同。单向SSL只需要服务器出示证书,双向则需要双方交换证书并验证。可能还要说明应用场景优缺点,比如双向更安全但更复杂。 还要注意术语的正确性,比如单向SSL有时也被称为服务器认证SSL,双向则是相互认证或客户端认证SSL。另外,提到握手过程的不同,双向在握手时会要求客户端发送证书,而单向不会。 最后,要确保用中文解释清楚,结构清晰,分点说明,可能用例子帮助理解。比如电商网站用单向,银行转账用双向。同时提醒用户,虽然SSL这个词常用,实际现在多用TLS协议,不过习惯上仍称SSL。</think>### 单向SSL双向SSL的区别用途 #### 1. **单向SSL(单向认证)** **核心特点**:仅服务器向客户端证明身份,客户端无需提供证书。 **验证流程**: - 客户端发起请求(如访问 `https://example.com`)。 - 服务器返回自己的SSL证书。 - 客户端验证证书是否由受信任的CA签发,并检查域名是否匹配。 - 验证通过后,建立加密通信。 **应用场景**: - 大多数公开网站(如电商、新闻网站)。 - 用户通过密码或短信验证身份,而非证书。 **优点**: - 实现简单,用户体验友好。 - 无需管理客户端证书。 **缺点**: - 仅验证服务器身份,客户端身份可能被伪造。 --- #### 2. **双向SSL(双向认证)** **核心特点**:服务器客户端需互相验证身份。 **验证流程**: - 客户端发起请求。 - 服务器返回证书,并要求客户端提供证书。 - 客户端发送自己的证书。 - 双方验证对方证书的合法性(CA签名、有效期等)。 - 验证通过后,建立加密通信。 **应用场景**: - 高安全需求的内部系统(如银行、政府机构)。 - 企业间API通信(确保双方为授权实体)。 **优点**: - 双重身份验证,安全性更高。 - 防止中间人攻击或非法客户端接入。 **缺点**: - 需为每个客户端颁发管理证书,运维成本高。 - 客户端需预先安装证书,使用门槛较高。 --- ### **对比总结** | **维度** | **单向SSL** | **双向SSL** | |-------------------|------------------------------|------------------------------| | **验证方向** | 仅服务器→客户端 | 服务器↔客户端 | | **证书需求** | 服务器证书 | 服务器证书 + 客户端证书 | | **安全性** | 中等 | 高 | | **典型场景** | 普通网站、公开服务 | 金融系统、企业内网、IoT设备 | | **实现复杂度** | 低 | 高 | --- ### **技术补充** - **术语说明**:SSL(Secure Sockets Layer)已升级为TLS(Transport Layer Security),但习惯仍称“SSL”。 - **证书类型**:双向SSL中,客户端证书需由私有CA或公共CA签发,需提前部署到客户端。 - **握手过程差异**:双向SSL在TLS握手阶段多了一步客户端证书交换(`CertificateRequest` `CertificateVerify`)。 **示例代码(简化握手流程)**: ```plaintext # 单向SSL握手 Client → Server: "Hello" Server → Client: 证书 Client: 验证证书 Client → Server: 生成会话密钥(用服务器公钥加密) Server: 解密密钥,开始加密通信 # 双向SSL握手 Client → Server: "Hello" Server → Client: 证书 + "请提供你的证书" Client → Server: 客户端证书 Server: 验证客户端证书 Client: 验证服务器证书 双方生成密钥,开始加密通信 ``` 实际应用中,单向SSL足以满足多数场景,而双向SSL适用于对客户端身份有严格要求的系统。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值