신비한 비

RADIUS는 Remote Authentication Dial-In User Service의 약자로 AAA 기능 구현을 위한 인증 프로토콜.

RADIUS는 ISP(Internet Service Provider)에서 사용하는 H/W 또는 S/W 등에 의한 원격 접속에 대한 인증용 서버를 지칭합니다. 즉, 원격의 사설 접속자 또는 무선 랜을 통한 접속을 그룹웨어, 무선 AP 등에 연결하기 전 사용자의 인증 및 인가를 하기 위한 서버 입니다.

구성요소:

• 사용자:

  실제 서비스 사용을 위해 서버에 접속하는 사용자

• RADIUS 클라이언트 (인증 에이전트)

  VPN (Virtual Private Network): 가상 사설망, 사용자와 인터넷 사이의 보안 통신을 구축하는 개념  WLAN (Wireless Local Area Network): 전파를 통해 장비 간 네트워크를 구축하는 방식  AP (Access Point) / WAP (Wireless Access Point): 유선 LAN과 무선 LDAN을 연결하는 장치 (공유기 등)  NAS (Network Access Server): 인증을 처리하고 네트워크 지점 간 프로토콜 연결을 위한 장치

• RADIUS 서버 (인증 서버)

  인증을 위한 주요 자격 정보를 저장 및 관리하는 서버

특징

구성:

내저장소 바로가기 luxury515

뭐 제목은 거창하지만 내용은 별거 없을것 같다. 어로그 끌어서 미안하지만 …

일단 설명을 하자면 NPE를 방지하기 위한 노력은 예전부터 많은 JAVA 개발자들이 세세대대 이어져왔다.

아직도 개발도중에 NPE 은 우리를 항상 괴롭히기도 한다.

뭐 아시다싶이 apache Commons Utils 를 이용하여 String , Object 에 대한 null 체크를 대부분은 하고 있다. 하지만 오늘 얘기할 부분은 Optional 클래스에 위임하는 방식이니 이해하고 그냥 읽어만 달라.

가끈 팀프로젝트에서 해당 클래스를 이용해서 null 체크하라는 지시가 있을때 하려고하면 항상 까먹곤 하니 오늘 좀 자주쓰는 부분을 적어보자.

public OrderDto getOrderDto(Long orderId) {
    QOrder order = QOrder.order;
    QUser user = QUser.user;
    QItem item = QItem.item;

    OrderDto orderDto = queryFactory
        .select(Projections.constructor(OrderDto.class, order, user))
        .from(order)
        .leftJoin(order.user, user)
        .where(order.id.eq(orderId))
        .fetchOne();

    if (orderDto == null) {
        throw new NotFoundException("Order not found");
    }

    List<OrderItemDto> orderItemDtos = queryFactory
        .select(Projections.constructor(OrderItemDto.class, item))
        .from(orderItem)
        .join(orderItem.item, item)
        .where(orderItem.order.id.eq(orderId))
        .fetch();

    orderDto.setOrderItemDtos(orderItemDtos);

    return orderDto;
}

아래와 같이 개선 해보았다.

public OrderDto getOrderDto(Long orderId) {
    QOrder order = QOrder.order;
    QUser user = QUser.user;
    QItem item = QItem.item;

    OrderDto orderDto = queryFactory
        .select(Projections.constructor(OrderDto.class, order, user))
        .from(order)
        .leftJoin(order.user, user)
        .where(order.id.eq(orderId))
        .fetchOneOptional()
        .orElseThrow(() -> new NotFoundException("Order not found"));

    List<OrderItemDto> orderItemDtos = queryFactory
        .select(Projections.constructor(OrderItemDto.class, item))
        .from(orderItem)
        .join(orderItem.item, item)
        .where(orderItem.order.id.eq(orderId))
        .fetch();

    orderDto.setOrderItemDtos(orderItemDtos);

    return orderDto;
}

내저장소 바로가기 luxury515

path:

/opt/homebrew/Cellar/tomcat@9/9.0.65/libexec

내저장소 바로가기 luxury515

갑자기 후임이 “IPv6가 뭐고 , IPv4와 비교하면 어떤 장점” 있나요? 질문은 한다.

순간 생각나는 대로 대답해줬는데 뭔가 이해가 안된 표정.

그래서 나름대로 찾아서 정리해 보았다.

ipv6 를 출시하게 된 배경.

기존 ipv4는 32bit로 식별되며 이론적으로 제공할 수 있는 주소의 수는 약 43억 개라고 한다. (이렇게 많은데도 부족하다니… ㅜ.ㅜ )

또한 IPv4 주소의 할당도 불균등하여 미국은 전 세계 주소 공간의 약 절반을 차지하며 유럽은 상대적으로 부족하고 아시아 태평양 지역은 더욱 부족하다고 한다.

그리고 최근 모바일 IP와 광대역 기술의 발전은 더 많은 IP 주소를 필요로 한다. 현재 IPv4 주소가 소진되었다고 한다. IPv4 주소 부족에 대한 몇 가지 해결 방법이 등장하기도 했다.

CIDR과 NAT이 대표적이다.그러나 CIDR과 NAT은 각각의 단점과 해결할 수 없는 문제를 가지고 있어 IPv6의 발전에 가속페달을 밟게 함.

IPv6 주소는 128bit로 식별되는데 128bit의 주소 공간을 통해 IPv6는 이론적으로 약(43억 x 43억 x 43억 x 43억)개의 주소를 가질 수 있다고 한다. 거의 무한에 가까운 주소 공간인데… 그럼 128 아닌256 512도 나오는거 아님? ^^ 우리같은 빡대가리들은 그냥 출시되면 그대로 쓰면 될것 같다!!!.

메시지 처리 측면에서 IPv4 헤더에는 Security, Timestamp, Record Route 등과 관련된 Options(옵션 필드)가 포함되어 있다. 이러한 Options는 IPv4 헤더의 길이를 20 Byte에서 60 Byte로 확장할 수 있다. 이러한 Options를 운반하는 IPv4 메시지를 전달하려면 소프트웨어로 중간 경로 전달 장치를 처리해야 하는 경우가 많으므로 성능 오버헤드가 크므로 실제로 거의 사용되지 않는다.

IPv6는 IPv4에 비해 메시지 헤더는 Internet Header Length, Identifier, Flag, Fragment Offset, Header Checksum, Options 및 Padding 필드를 제거하고 스트림 태그 필드만 추가하므로 IPv6은 IPv4에 비해 메시지 헤더를 훨씬 더 쉽게 처리하고 처리 효율성을 향상시킨다. 또한 IPv6는 다양한 옵션의 처리를 보다 잘 지원하기 위해 확장된 헤더의 개념을 제시하였으며, 새로운 옵션의 경우 IPv6 헤더의 구조를 수정할 필요가 없으며 이론적으로 무한히 다양한 옵션을 확장할 수 있어 뛰어난 확장성을 구현하였다.

주소 유지보수의 경우 IPv4 주소가 32bit에 불과하고 주소 할당이 불균형하여 네트워크 용량 확장 또는 재배포 시 IP 주소를 재할당해야 하는 경우가 많으므로 유지 보수 작업량을 줄이기 위해 IP 주소를 자동으로 구성하고 재주소할 수 있는 메커니즘이 필요함.현재 IPv4의 자동 구성 및 재코딩 메커니즘은 주로 DHCP에 의존함. IPv6 프로토콜은 자동 주소 설정을 통해 호스트가 네트워크를 자동으로 검색하고 IPv6 주소를 얻을 수 있는 메커니즘을 내장하여 내부 네트워크의 관리성을 크게 향상시킴.

라우팅 집약의 경우 IPv4 개발 초기 주소 할당 계획 문제로 인해 할당된 많은 IPv4 주소가 불연속적이어서 라우팅을 효율적으로 집약할 수 없음.점점 더 많은 양의 라우팅 테이블은 많은 메모리를 소비하여 장비 용량과 전송 효율에 영향을 미치므로 장비 제조업체는 라우팅 주소 지정 및 전송 성능을 향상시키기 위해 제품을 지속적으로 업그레이드해야 한다. IPv6의 거대한 주소 공간은 IPv6가 계층화된 네트워크를 쉽게 배치할 수 있도록 한다.계층화된 네트워크 구조는 라우팅 집합을 보다 쉽게 만들고 라우팅 및 전달의 효율성을 향상시킨다.

엔드 투 엔드 보안의 경우 IPv4 프로토콜을 개발할 때 보안에 대한 시스템 설계가 부족하여 고유한 프레임워크 구조가 엔드 투 엔드 보안을 지원하지 않는다. IPv6에서 네트워크 계층은 IPsec의 인증 및 암호화를 지원하며 엔드 투 엔드 보안을 지원한다.

QoS 보장 측면에서 인터넷 회의, 인터넷 전화, 인터넷 TV의 급속한 대중화와 사용으로 고객은 오디오 및 비디오 업무의 실시간 전송을 보장하기 위해 더 나은 QoS를 요구하지만 IPv4는 QoS를 보장할 특별한 수단이 없습니다. IPv6에는 QoS 보장에 사용할 수 있는 스트림 태그 필드가 추가되었다.

이동성 지원 측면에서 모바일 IPv4에는 삼각 라우팅, 소스 주소 필터링 등과 같은 몇 가지 문제가 있다. IPv6 프로토콜은 이동성을 지원해야 한다고 규정하고 있다.모바일 IPv4에 비해 모바일 IPv6는 외부 에이전트를 사용하지 않고 외부 네트워크를 직접 검색하고 주소를 전달할 수 있다.동시에 라우팅 확장 메시지 헤더와 목적 옵션을 사용하여 메시지 헤더를 확장하면 모바일 노드와 피어 노드 간에 직접 통신할 수 있으며 모바일 IPv4 삼각 라우팅 및 소스 주소 필터링 문제를 해결하여 이동통신 처리 효율을 높이고 애플리케이션 계층을 투명하게 한다.

내저장소 바로가기 luxury515