📌 HYPER TEXT TRANSFER PROTOCOL

📖 Hypertext란?

참조링크를 통해, 독자가 다른 문서로 즉각적으로 이동할 수 있는 문서로 순차적 나열적 구조가 아닌, 사용자가 임의로 나열하는 구조를 가진다.

📖 HTTP란?

인터넷 상에서 데이터를 주고 받기 위한 프로토콜

• 클라이언트와 서버 간의 통신 (웹사이트를 로드 하는데 필요한 정보를 요청하는 방법)
• World Wide Web의 통신 방법
• 요청 & 응답 방식의 애플리케이션 계층의 통신
• 단방향성 (하나의 요청에 하나의 응답)

📖 HTTP의 단점

데이터를 평문으로 보낸다

• 도청 및 데이터 변조 + 패킷 가로채기 가능 => HTTPS (Secure)

📖 HTTP method

1. GET 주로 조회에 사용되며, 서버의 데이터를 수정하는데에 사용해서는 안됨 => 따라서 GET 요청은 멱등성을 가진다. (다 회 시도에 따른 서버의 변경 및 리턴이 바뀌지 않음)

• 조회 정보를 URL의 쿼리 파라미터로 전달
• 요청시 본문(Body) 및 ContextType이 없음
• 캐싱 가능 (캐싱 2번 @Cacheable활용 부분은 후에 추가적으로 redis를 사용하는 부분과 묶어서 글 작성!)

1. 클라이언트 캐싱 (백엔드에서는 유도만)

    @GetMapping("/items/{id}")
    fun getItemWithETag(
        @PathVariable id: Long,
        request: HttpServletRequest
    ): ResponseEntity<ItemDto> {
        val item = itemService.getItem(id)
        val etag = "\"" + item.hashCode().toString() + "\""  
   
        // 클라이언트가 보내온 ETag와 비교
        val clientETag = request.getHeader("If-None-Match")
        if (clientETag != null && clientETag == etag) {
            return ResponseEntity.status(HttpStatus.NOT_MODIFIED).eTag(etag).build()
        }
   
        return ResponseEntity.ok()
            .eTag(etag)
            .cacheControl(CacheControl.maxAge(60, TimeUnit.SECONDS).cachePublic())
            .body(item)
    }

클라이언트 캐싱 상세 과정

1. 서버는 ETag를 응답 헤더에 넣어서 보냄

   ETag: "123456"
   Cache-Control: public, max-age=60

2. 클라이언트(브라우저 또는 프록시)가 이 응답을 저장하고 이후 다시 같은 URL 요청 시, 클라이언트는 If-None-Match: 부분을 추가

GET /items/1
If-None-Match: "123456"

3. 서버는 현재 데이터로부터 ETag 생성 (hashCode, 또는 content 기반 hash 등)

[ 예시에서는 단순히 item을 hash처리해서 ETag 생성 ]

  val etag = "\"" + item.hashCode().toString() + "\""  

[ 클라이언트가 보낸 ETag와 동일한지 확인 하는 코드 ]

if (clientETag == etag) {
    return ResponseEntity.status(HttpStatus.NOT_MODIFIED).eTag(etag).build()
}

서버는 본문(body)을 전혀 보내지 않고, HTTP 304 Not Modified 응답만 내려줌. → 즉, 클라이언트가 기존에 저장한 데이터를 그대로 사용함!

2. @Cacheable을 활용한 서버 측 캐싱 (이후에!!!)
   

2. POST 주로 새로운 데이터 생성에 사용되며, 부모 리소스의 하위 리소스를 생성하는데 사용 => 따라서 POST 요청은 멱등성을 가지지 못한다. (동일한 요청이라도, 리소스를 중복으로 만들어 다른 리소스가 생성)

• body를 반드시 포함 (Context-Type도 필수)
• 정상적으로 리소스가 생성될 시 201(Created)로 응답

3. PUT
주로 기존 데이터 수정에 사용 => 중요!!! PUT 요청은 멱등성을 가진다. (수정은 하나의 리소스를 대상으로 하기 때문에 덮어씌워짐 = 멱등성 보장)

• body에 변경된 데이터 내용을 반드시 포함 (Context-Type도 필수)
• URL을 통해 어떤 리소스 수정할지를 지정해야함 (PUT /member/1)

4. DELETE

기타

• HEAD (vs GET) : GET과 유사하지만, 헤더만 조회하기 때문에, body데이터가 없어 더 빠른 조회 가능 예시, HEAD /my-profile/image.png 형식이면, GET 방식에 비해 이미지가 존재하는지, 크기가 얼마인지의 정보를 빠르게 얻을 수 있다.

• PATCH (vs PUT) RESTful하게 사용한다면, PUT은 id를 제외 모든 데이터를 덮어씌우고, return을 전체 데이터 / 그에반해 patch는 원하는 속성만 수정하고, return을 수정된 값만 보낸다.

• => 즉 PUT은 이론상 해당 리소스의 모든 데이터가 DTO에 포함되어야 하는게 맞음*

• OPTIONS : 서버에서 지원하는 메서드 목록 확인

• CONNECT : 프록시 동작의 터널 접속 변경 (프록시 서버 역할)

📖 HTTP 응답 코드

📌 HTTP/1.0

하나의 연결에 하나의 요청을 처리(즉 모든 요청마다 3-HANDSHAKE) RTT(Round-Trip Time) 클라이언트의 요청에 따라 서버로 응답을 받을 때까지 걸리는 시간 (즉, 왕복 시간)

• 기본적으로 3-HANDSHAKE의 RTT를 1.5
• 요청 또는 응답 1번의 RTT를 1로 보는데 HTTP/1.0에서는 최소 2.5RTT 연결 및 첫 요청까지 매 요청마다 소비 (비효율적)

따라서 이미지를 처리할 때 서버와의 연결을 또 열고, 받는 방식이 매우 부담이 되기 때문에 아래와 같은 방법을 통해 요청을 최소화 함

• 이미지 스플리팅 (하나의 큰 이미지로 받고, 좌표값(css의 postion)으로 나눠서 이미지를 사용)
• 이미지 Base64 인코딩 (이미지를 64진법의 문자열로 인코딩) => 현재 사용 중인 url 방식은 이미지 자체를 보내지 않고, 주소값으로 필요할때 재요청 하는 방식 / Base64는 이미지 자체를 인코딩해서 문자열로 통신에 사용하고, 이를 클라이언트가 직접 디코딩하면 이미지 파일로 만들어지는 방식 (미리보기에 많이 사용됨)

📌 HTTP/1.1

keep-alive 옵션을 통해 한번 연결됬을 때 여러 개의 파일 처리(최초 한번의 요청에서 3-HANDSHAKE 이후 통로를 keep-alive로 열어두는 방식) 단점 : Head-of-Line Blocking

📖 HOL Blocking

HTTP/1.1 처리 흐름 (단일 연결) [HTML-CSS-JS...] HTML 요청 HTML 응답이 완전히 끝나야 CSS 요청 시작 CSS 응답 끝나야 JS 요청 시작 ...

리소스 수가 많을수록 요청이 직렬로 병목 발생 => CSS 전달 과정이 느리게 받아지게 되면, 후에 받는 JS, JPG 등도 다운로드가 지연됨

📌 HTTP/2

📖 SPDY란?

2012년쯤 웹페이지들이 더 많은 리소스로 동적으로 구성되며, 다수의 도메인을 가짐과 동시에, 보안이 중요한 이슈가 되었다. 이에, latency와 보안 측면에서 HTTP를 보완한 SPDY 프로토콜을 GOOGLE에서 발표했다. -Multiplexing, HTTP 헤더 압축, 바이너리 프로토콜, TLS(Transport Layer Security) 위에서 동작 등의 특징을 가지고 있었지만 HTTP/2로 버전이 업데이트 되며, 현재는 지원이 중단되었다.

📖 Multiplexing

스트림을 여러개 사용한다. 특정 스트림에서 병목 현상, 패킷 손실이 발생하더라도, 다른 스트림에는 영향을 주지 않게 => 데이터를 프레임으로 쪼개서 병렬적으로 처리! => 단 하나의 데이터를 쪼갠 프레임은 하나의 스트림에서만! => 애플리케이션 단계에서의 HOL Blocking은 해결 가능 (TCP 단계에서는 X)

*질문 1 : /index.html 파일이 A,B,C 프레임으로 쪼개져서 각 스트림에서 전달된다? => HTTP/2.0단계에서 이 질문의 잘못된 점과 B프레임이 손실 되었을 때 어떻게 처리 될지를 설명하시오! *

📖 헤더 압축

HTTP/1.1 문제점 요청마다 중복된 헤더가 계속 전송됨 (예: User-Agent, Cookie, Authorization 등) 리소스가 많은 웹 페이지에서는 → 수십 번 같은 헤더가 반복됨

HPACK(Header Compression for HTTP/2) 클라이언트와 서버가 서로 동일한 헤더 테이블을 가지고 테이블에 이미 존재하는 헤더를 인덱스 번호로 전송하는 방법

허프만 트리 트리 방식을 참고해서 가장 빈도수 많은 문자를 root = 0으로 해서 빈도수가 적은 값을 위로 위치하게 하는 방식

• Prefix-Free Code (접두어가 겹칠 수 없게 = 알아보기 쉬움) 0 01 011 이런식이라면 디코딩 과정에서 어디서 끊어야할지 알 수 없음 따라서 상위 비트가 이전 비트와 겹치지 않게 설계 결국 특정 문자의 빈도수 현재 표에서는 F의 빈도수가 높으면 높을 수록 압축률이 높다.

=> HPACK의 index는 이와 같은 방법으로 생성되어 빈도수가 높을 수록 낮은 비트(적은 용량)를 할당하고, 만약 헤더 테이블에 없으면, 현재 테이블에 허프만 트리 방식으로 index를 설계해서, 추가한다.

📖 서버 푸시

기존 HTTP/1.1에서는 HTML -> CSS -> JS -> JPG 순으로 요청이 올때까지 기다려야 했다면, HTML을 요청했을 때, 서버에서 요청을 받기 전에, HTML내에 필요한 CSS, JS, JPG 먼저 전송 가능

📌 HTTP/3 (HTTPS + QUIC)

기존 TCP 사용하던 HTTP/2의 단점을 해결하고자, UDP 방식을 사용하는 HTTP 신규 프로토콜

📖 QUIC(Quick UDP Internet Connections)

이전에 UDP는 TCP에 비해 안정성이 떨어지기 때문에 활용도가 낮다라고 공부한적이 있다. 이를 최신 기술을 통해, UDP의 안정성을 Internet 환경에서 TCP 수준 또는 그 이상으로 만든 것을 QUIC라고 한다.

아래는 기존 UDP 방식에서 QUIC가 되며 바뀐점들 + HTTP/2와 비교한 것

1. 안정성 TCP처럼 패킷 번호를 부여 손실을 확인하고 재전송 요청

• vs TCP : TCP는 손실된 데이터를 ACK를 통해 확인 즉 뭐가 빠진지는 정확히 판단하지 못하는 반면, QUIC 방식은 송신자 측은 RTO(타이머)방식으로 패킷 재전송 시도 및 빠진 패킷 번호를 수신사측에서 확인하고 재요청

2. 흐름제어 수신자는 네트워크 혼잡도를 확인해 TCP처럼 처리 가능량을 송신자에게 전달 (패킷 유실 방지) like “한 번에 100KB까지만 보내줘”라고 통지

• vs TCP : 연결 전체 단위 뿐만 아니라 스트림 단위까지 두 가지 레벨의 흐름제어

3. 복구

TCP 단계의 HOL BLOCKING이 없는 복구

스트림 1: [A][B][C] 스트림 2: [X][Y][Z]

[TCP] → 만약 [B] 패킷 손실 → TCP는 전체 순서를 멈추고 B 재전송까지 기다림 → 스트림 2의 [X], [Y], [Z]도 도착해도 처리 못 함 (HOL 블로킹)

[QUIC] → [B] 손실 → QUIC이 [B]만 재요청 → [X], [Y], [Z]는 스트림 2로 독립 전송 및 처리 가능 → 전체 처리 지연 없음

결론 QUIC는 UDP로 TCP의 거의 모든 장점을 기술로 구현해낸 방식 (동일한 처리 + 속도 우수)

📖 Zero round-trip time (0-RTT)

한 번 HTTP 연결이 이루어지고 나면, 클라이언트는 더 이상 handshake를 통해 통신 방법을 확인하려 서로를 확인하는 프로세스를 진행하지 않는다 (간결한 통신)

📖 HTTPS가 선택이 아닌 필수

• HTTP/2까지는 선택 사항
• HTTP/3부터는 TLS 1.3을 내장시켰기 때문에 필수

📌 HTTPS

애플리케이션 계층과 전송 계층 사이에 [신뢰 계층] 추가

📖 SSL/TLS

SSL/TLS(신뢰 계층) = 전송 계층에서 보안을 제공하는 프로토콜

1. 보안 세션을 위한 키교환 진행 (handshake의 마지막 부분)
2. 보안 세션동안 cyper suites라는 암호화 알고리즘 리스트를 클라이언트와 서버가 통신 (후에 어떤 알고리즘을 써서 암호화해서 보내고, 풀지를 결정)
3. CA에서 발급한 인증서 기반으로 인증 메커니즘 진행
4. 해싱 등으로 알고리즘

📖 디피-헬만 키 교환 알고리즘

y = g^x * (mod p) => 공개 값을 공유해서 각자 비밀 값과 연산하여, 혼합 값을 공유하면 공통의 암호키를 생성할 수 있는 원리

• 예시) ECDHE (쉽고 안전한 디피-헬만 알고리즘 변형) 클라이언트 서버 개인키: a 개인키: b 공개키: A = a·G 공개키: B = b·G 수신 공개키: B 수신 공개키: A 공통 키: K = a·B 공통 키: K = b·A => 중간에서 A, B를 모두 알아도 a나 b를 모르면 K를 연산하기 힘듬

📖 SHA-256

어떤 길이의 값을 입력해도 256비트의 고정된 결과값을 출력하는 알고리즘 내부 과정은 매우 복잡하지만 간단히 설명하면

• 전처리 과정에서 어떠한 데이터든지 확장해서 512비트로 만들고
• 이를 32bit의 8조각으로 쪼개서, 복잡한 연산(비트수는 바뀌지 않음)을 진행

[Merkl–Damgård Algorithm & RoundFunction =복잡한 연산] => [입력 블록 512비트] + [현재 상태 256비트] → 새로운 상태 256비트 => 이 복잡한 연산은 이전 조각을 매개변수로 이용 A,B,C 면 B를 만들 때는 A가 사용되고, B의 값이 업데이트가 된 후에는 C를 만들 때 사용됨

• 이를 다시 이어 붙임 = 256bit 유지

*질문 2 : 문자가 512bit를 넘어가면? *

📌 네트워크 기기

📖 처리 범위

계층 별로 처리하되, 상위 계층은 하위 계층을 처리할 수 있다.

즉 애플리케이션 계층의 L7 스위치는 인터넷 계층에서, IP에 따른 분배도 가능하고, 데이터 링크 계층에서 MAC 주소에 따른 패킷 분배도 가능하다

📖 대표 기기(하드 웨어)

애플리케이션 계층 : L7 스위치(로드 밸런서)

인터넷 계층 : L3 스위치(라우터)

*데이터 링크 계층 : L2 스위치 & 브릿지(LAN to LAN) *

물리 계층 : NIC(LAN 카드)

• 각 LAN 카드가 가지는 고유 식별 번호가 : MAC 주소!
  

📌 IP 주소

📖 주소 매핑

통신을 한다는 것은 어떤 PC와 PC가 연결된다는 것이기 때문에, 서로가 MAC 주소를 알아야한다!

결국 IP와 DNS 같은 것은 특정 컴퓨터 그룹에 접근을 쉽게하기 위한, 뼈대 주소이지 노드와 노드를 연결해 주지는 않음!!!

택배를 보낼때, "서울시 동대문구"만 보내서 찾아갈 수 없는 것과 같은 이치!

단순하게, 정적 테이블을 가지고 있으면 해결이 되나, IP는 DHCP등 여러 요인에 의해 지속적으로 변경되므로, 통신 프로토콜을 이용해서, IP라는 큰 범위의 주소를 통해서 빠르게 찾아가고, 이후 MAC이라는 다른 방법(전화?)으로 상세주소를 알아내어 통신!

📖 ARP, RARP

• ARP는 주소 결정 프로토콜(Address Resolution Protocol, ARP)로 IP주소를 MAC주소로 대응시키는 프로토콜

• RARP는 역순 주소 결정 프로토콜(Reverse Address Resolution Protocol, RARP)로 MAC 주소에 맞는 IP값을 알아오는 프로토콜

RARP의 한계: RARP는 IP 주소만 알려줄 수 있기 때문에 통신을 위해 subnetMask, 라우터의 등 다른 정보가 필요한 현대 통신에서는 DHCP 등으로 대체

중요 ARP와 RARP는 같은 그룹 내 = 동일한 라우터에 연결 = 동일한 서브넷 IP를 가지는 경우에만 이용 가능

먼저 Request broadcast(1:N)는 L2 스위치에 "나 이 IP 주소의 MAC주소 알고 싶어"라고 하는거고 이는 L2 스위치가 가진, MAC주소 테이블에 의해 연결된 모든 노드에 브로드캐스팅 된다.

이후에 해당 IP를 가진 노드가 Reply unicast(1:1)를 L2 스위치에 보내 "이 IP는 내 주소야, 나 여기있어"라고 인식시키고, 이를 스위치가 다시 reqeust 요청을 보낸 노드에게 보내는 방식

📌 라우팅

📖 어떻게 찾아갈까?

통신 장치는 각각 자신의 범위를 지정하고 있다. 즉 자신의 범위 밖까지는 연결해 줄 수 없다. 각 통신장치는 라우팅 테이블을 가진다. 목적지 IP를 확인하고, 라우팅 테이블 내 다음 통신장치로 연결

즉 서울특별시 이면, 서울 택배 허브로, 충북이면 충북 택배허브로 보내는 방식

📖 라우팅 테이블

• 네트워크 대상(Network Destination) : 목적지 네트워크의 IP 주소
• 서브넷 마스크(Netmask) : 대상 주소를 설명할 때 쓰이는 값
• 게이트웨이(Gateway) : 이 장치와 연결되어있패킷이 전달되는 다음 IP 주소(외부 네트워크와 연결된 장치) 만약 목적지가 로컬 네트워크라면 “연결됨(connected)”라고 표기 되며 다른 네트워크라면 해당 네트워크의 게이트웨이를 가리킴
  

GATEWAY

서로 다른 네트워크간의 통신을 위해서는 반드시 필요한 일종의 "대문" 역할로 따로 지정한 Host IP의 일종

📖 클래스 기반 IP 할당과 서브넷 마스크

IP는 Byte 단위 즉 8개의 0,1로 표현된 범위를 나뉘어서 네트워크 주소와 호스트 주소를 구분한다.

이를 구분하는 키를 subnetMask 라고 하고, 이는 1이 연속되어 나오다, 0으로 바뀌는 지점이 생기도록 디자인하며, 1의 개수를 이용하여 /24 와 같은 형태로 작성한다.

예시) 255.255.255.0 1111 1111 . 1111 1111 . 1111 1111 . 0000 0000

*질문 1 : 192.168.0.0/20의 네트워크 범위, 호스트 범위, 네트워크 주소, 브로드 캐스트 주소? *

📖 DHCP

DHCP(Dynamic Host Configuration Protocol)는 네트워크의 장치가 IP 주소를 요청하고 할당받을 수 있도록 하는 네트워크 프로토콜

• 서브넷 마스크 및 게이트웨이와 같은 다른 매개변수를 네트워크의 장치에 자동 할당

DHCP Ack에서 임대 기간과, IP를 받음

• 장치가 네트워크에서 제거되거나 임대가 만료되면 사용 중이던 주소를 사용 가능한 주소 풀로 반환하고 다른 장치에 재할당

** 질문 2? : DHCP 서버와 클라이언트가 서로 다른 서브넷을 가질때?**

📌 CI/CD 구조 (1.Build)

시험 하나 남았는데 회로 공부하다가 잠깐 쉬어가는 겸 블로그 글 업로드 시작!

📖 무슨 내용인가? (요약)

앞으로 "CI/CD의 구조"라는 주제로 적을 내용은 서버 이전 프로젝트를 진행하기전에, 강의 형식으로 CI/CD의 과정이 어떻게 되는지 현업자 대! 준수님이 설명해준 내용을 내 맘대로 정리한 내용이다. 이전에는 기본적인 형태만 잡고 있었다면, 각 과정을 순차적으로 잘 설명해줘서, 해당 내용과 추가적인 공부 + 알고 있던 지식을 함께 정리해 보려한다.

일단 설명하기 전에, 준수님은 뭐든지 주체와 도구의 구분이 중요하다고 했기 때문에 이 부분을 중점으로 다뤄보겠다!

📖 1. Build

Build (도구 : gradle)

소프트웨어 빌드(software build)의 정의는 소스 코드 파일을 실행할 수 있는 독립(standalone) 소프트웨어 가공물로 변환하는 과정이다.

빌드는 코드를 ,패키징 해서, 어떠한 배포가능한 형태로 만드는 과정

자바 환경에서 설명해보면

• 먼저 코드는 .java형태로 작성
• 이후 컴파일러에서 .java를 바이트 코드인 .class로 변환하고 (문법 오류 체크 포함!)
• JVM에서 .class파일을 메모리에 할당하고, 바이트코드를 해석 및 실행 (여기 부터를 Runtime이라고 부름!)
• 사실상 이 과정이 build의 끝

[.class] build의 문제점

여러 클래스의 상호작용을 위해 "java -cp"와 같은 명령어로 class-path를 지정해주어야 하고, 파일이 하나라도 없으면 실행 자체가 안되는 문제가 발생!

[.jar] 패키징

• 각 클래스 파일들
• class-path연결
• 리소스 파일 (.yml, .xml)
• 메타데이터
• fat jar를 통한 라이브러리 연결 등을 묶어서 zip 형식으로 묶어서 한번에 build가 되게!

이 과정을 진행해 주는 것이 바로 Gradle

Gradle

1) 기본 구조

plugins {
    id 'java'
}

group = 'com.example'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.8.2'
}

test {
    useJUnitPlatform()
}

build.gradle ├── plugins: "나는 Java 프로젝트야!" ├── group / version: 프로젝트 식별자 설정 ├── repositories: "라이브러리 어디서 받을까?" ├── dependencies: "어떤 라이브러리 쓸까?" └── test: "JUnit5 기준으로 테스트할게!"

기본적으로 gradle은 plugin과 dependecy 그리고, dependency를 어디서 가져올지를 결정하는 repository로 결정된다. (mavenCentral은 세계 최대 오픈 소스 저장소!)

plugin과 dependecy의 차이가 무엇인가?

Plugin은 gradle에게 이 프로젝트에 대해서 설명하고, 해야할 작업을 알려주는 것! Dependecy는 내 소스 코드를 실행할 때 필요한 라이브러리

Plugin : "빌드 툴을 업그레이드" (Gradle 자체 upgrade) Dependency : "내 소스 코드를 업그레이드" (코드 자체에 기능 추가)

🔨 플러그인은 빌드 공장에서 일하는 로봇을 추가하는 거고, 📦 의존성은 내 제품(앱) 안에 들어가는 부품을 추가하는 것!

2) 각 과정

0. clean : 이전 빌드 결과물 초기화
1. compileJava : javac(컴파일러)를 호출 해서 .class로!
2. prcessResources : 리소스 파일을 .class와 함께 복사
3. jar : 복사한 .class와 resource를 묶어서 jar파일 만들기
4. test : Junit과 같은 테스트 프레임워크를 활용한 테스트 진행

- 1+2 : gradle classes - 1+2+3 : gradle assemble - 1+2+3+4 : gradle build (assemble + test)

결과 : .class 파일을 적당히 묶고 리소스 같은 것들도 추가해서 .jar파일로 만들어냄!

📖 0단계 : Build 이전 과정 (for 자동 배포)

결국 jar 파일을 서버 컴퓨터로 옮겨서 jvm으로 실행하는게 최종 목적인데, 이걸 내가

• 변경 사항이 있을 때 마다
• 직접 .jar로 만들고(build)
• 서버 컴퓨터로 파일을 옮겨서 실행하면,

CI/CD의 의미가 없다!

📖 자동화

보통은 github repository에 특정 조건(브랜치나, 태그) 등을 활용해서 push 했을 때, 원하는 주소로 webhook을 보내 변경사항을 감지한다!

이후에는 변경된 코드를 자동으로 build하고, 2번 과정인 도커 이미지로 만드는 과정까지 진행 => 이전 프로젝트에서는 이 과정을 jenkins라는 툴의 pipeline을 이용!!!

📌 네트워크 기초

📖 노드와 링크

노드는 네트워크 장치 링크는 무선 또는 유선으로 연결된 상태를 의미한다.

📖 처리량과 대역폭

네트워크에 트래픽(데이터)이 전달되면 이는 디지털 신호이기 때문에 0 또는 1즉 bit 데이터로 전달된다. 이때 처리량(throughtput)은 1초에 수신되는 bit의 수(bps)를 의미하고, 이 처리량을 단위 시간 당 max값으로 설정한 것을 대역폭이라고 한다. 따라서 대역폭과 처리량의 단위가 동일하다!

📌 네트워크 토폴로지

📖 토폴로지

토폴로지는 노드와 링크가 어떻게 배치되어 있는 지를 의미한다. 종류는 Tree, 회선에 여러개의 노드가 연결된 Bus, 노드끼리 1대다 관계의 스타, 노드끼리 1-1-1 관계의 링, 노드끼리 다대다 관계를 가지는 메시 구조가 있다.

📖 스푸핑 in Lan(Bus)

Bus 방식에서는 중앙 통신 회선하나에 여러개가 연결되어, 해당 노선을 따라 순차적으로 데이터가 전달된다. 따라서 중앙 통신 회선에 접속만 하면, 데이터를 송신부에서 수신부로 가기전에 가로 챌 수 있는 단점이 잇는데 이를 스푸핑 이라고한다.

• 주의 : 병목 현상이 발생했을 때, 회선 추가 및 대역폭 개선 등의 다양한 문제 해결방법이 있지만, 네트워크 토폴로지에 따른 올바른 방법을 적용해야 해결할 수 있다.
  

📌 네트워크 종류

• 기본적으로 규모가 클수록 혼잡하고 속도가 느리다.

  📖 WAN & MAN

• WAN은 국가 및 대륙 범위의 통신망을 의미하고, 인터넷이 WAN에 속한다. MAN은 동일 국가 내 통신망으로 지역을 이어주는 통신망이다.

  📖 LAN

• LAN은 근거리 통신망을 의미하고, 보통 라우터나, 공유기를 통해 연결된다.
  

📌 명령어

📖 Ping

가장 많이 쓰이는 Ping은 원하는 노드를 대상을 패킷을 보내 수신 상태 및 도달시간을 확인할 수 있는 명령어이다. ICMP 프로토콜을 기반으로 통신한다.

패킷의 헤더에는 송신 IP + 프로토콜 + 패킷 번호를 가진다.

ICMP는 TCP/IP(전송계층)에서 패킷을 처리할 때 발생되는 문제나 정상 응답을 받을 수 있는 프로토콜이다.

• Echo request는 ICMP에서 수신자에게 보내는 응답 요청 메시지를 담고 있으며
• Echo reply는 수신자가 보내주는 응답이 기록된다.
• Destination Unreachable는 전송실패 했을 때 즉, Echo reply와 반대의 상황에서 메시지가 저장되고
• 마지막으로 Time Exceeded는 ICMP데이터의 생명을 의미하는 TTL이 0이 되었을 때 메시지를 송신자에게 메시지를 반환한다.

TTL을 1씩 증가시켜가면선 모든 노드를 기록하는 방법 = Traceroute

• TTL을 1로 설정해서 패킷을 보내면
• 다음 노드로 가면 TTL이 0이 되고, TimeExceeded 메시지 전송
• 이후 다시 TTL을 1 증가 시키고, 다시 다음노드로 전달 반복 => 결과적으로 겨쳐간 모든 노드에서 TTL이 0이 한번씩 되기 때문에, 송신한 노드에서는 목적지까지의 모든 노드에서 반환한 메시지를 확인 가능!

질문 1 : NAT(외부에서는 포트번호로 접근) 즉 라우터를 사용하게 되면 traceroute방식에서 해당 목적지를 어떻게 찾아갈까

📖 nslookup

DNS(인터넷 상의 전화번호부)를 확인하는 명령어

내부 DNS 서버에 어떻게 외부에서의 접근을 막나?

DNS 즉 외부에서 확인할 수 있는 도메인 정보가 아니라, 외부에는 공개 되지 않는 도메인 주소를 형성하여 만드는 내부 네트워크 도메인이다. 보통은 bind라는 프로그램을 메인 서버에 설치!, 원하는 도메인과 내부 ip를 연결하여, 파일로 저장해서, 도메인 이 형성되는 방식

즉 어떤 도메인이 입력되면, 외부 DNS 확인하기전에, 내부 DNS를 확인해서 있다면 해당 ip랑 연결 해주고, 없다면 외부 ip를 탐색!

*질문 2 : 내가 만든 서버의 DNS가 A.com->B.com으로 바뀌었다. 다른 PC에서 내 서버ip로 DNS 테이블을 조회하면 A로 보일까 B로 보일까? 또 내 컴퓨터에서 nslookup을 하면 어떻게 보일까? *

📌 TCP/IP 계층 구조

📖 애플리케이션 계층 = 프로토콜 계층

• FTP는 파일전송, SSH 원격(암호화), HTTP(www. 인터넷), SMTP 메일전송 등이 있다.

  📖 전송 계층

  TCP와 UDP는 데이터 전송을 위한 프로토콜이다. TCP는 각 패킷을 순서대로 전달하고, 연결을 매 순간 확인하며 전달하는 방식이다. 즉 출발지에서 목적지까지 1차차로 연결이 성공하는 경로를 확인하고 그 경로로만 패킷을 전달한다. 그에 반해 UDP는 수신 여부를 확인하지 않고 데이터만 전달한다. 심지어 경로도 자유분방하다.

TCP연결 과정 및 해제 과정에서는 HANDSHAKE를 한다!

• 3handshake -> data -> 4handshake

[3handshake] TCP의 통신 노드는 ISN이라는 32-bit 시퀀스 번호(노드의 주민번호?)를 송신자가 보내고, 수신자가 받아서 자신의 ISN과 승인 응답으로 송신자의 ISN+1을 보낸 후, 다시 송신자가 받아서 승인 응답으로수신자의 ISN+1을 보내서 양방향으로 체크한 경우 통신을 시작한다. 이때 자신의 시퀀스 번호를 보는 과정을 SYN 승인 응답을 보내는 과정을 ACK라고 한다.

[data] 이후 인증된 TCP 통신 경로로 각 데이터를 교환하고

[4handshake] 통신을 종료하기 위해 FIN(종료 코드)을 송신자 측에서 전달하고 (1차 종료 상태), 수신자 측은 승인 응답인 ACK를 보낸다. 이 경우 ACK를 받은 송신자 측은 무응답 (2차 종료 상태) 이후 수신자 측은 응답이 없는 것을 확인하고 응답이 아닌 FIN을 처음으로 보낸다 (수신자 측의 마지막 통신). 이후 이를 받은 송신자는 2차 종료 상태에서 대기 상태로 전환되고, 승인 응답 전송한다. 이는 수신자가 받는 최종적으로 양뱡향으로 확인한 종료이기 때문에 수신자는 최종 CLOSED되고, 응답을 받을 수 없는 송신자는 대기하다가 time out되어서 CLOSED된다.

TCP 중간에 유실 되면

송신자는 데이터를 보냄과 동시에 이전에 통신한 기록을 기반으로 timeout을 설정한다. timeout이내로 데이터+ACK를 받지 못하면 해당 패킷을 재전송한다.

*질문 3? timeout을 송신자 쪽에서 스스로 계산한다면 똑같은 데이터를 중복으로 보낼 수 있지 않나? TCP는 연결성을 보장하고 중복 데이터는 없다 그랬는데? *

📖 인터넷 계층 : 원하는 IP 주소로 전송하기 위한 규칙

• 연결을 보장하지 않는다!

  📖 링크 계층

  광섬유 등을 이용하여 물리적을 데이터를 보내는 계층 + 이더넷 계층인데 주로 맥주소를 교환한다.

📌 계층 간 통신

결국 최종적으로 통신을 할때에는 여러 계층을 통과해야하고, 결국 각 과정에서 필요한 프로토콜들이 모두 전달되어야한다. 즉 PDU(계층에서 계층으로 전달되는 데이터)는 반드시 이전 단계의 프로토콜을 가진다.

캡슐화 즉 애플리케이션 계층에서 데이터는 전송 계층으로 넘어가면서 TCP나 UDP 프로토콜이 추가되고 (L4), 다시 인터넷 계층으로 전달되면서 IP 프로토콜 등이 추가(L3), 이후에 링크 계층으로 넘어가면서 MAC 주소 등이 추가 되서, 물리적으로 이동 된다 이후에 다시 위 과정의 역과정인 비캡슐화 과정을 통해 애플리케이션 계층의 데이터만 뽑아서 전달 된다.

📖 VPN

VPN은 외부 접근 불가 + 연결되어야만 확인할 수 있는 일종의 보안통로로 통신하는 방식이다.

VPN도 결국 계층간 통신 과정을 거칠텐데, 왜 중간 노드에서 확인할 수 없는 보안통로를 만들 수 있는 것일까? 똑같이 비캡슐화 과정을 하면 보이는게 아닌가? VPN에는 여러 방법이 있지만, 계층 간 통신과 연결을 하려면 IP 프로토콜 즉 L3단계에서의 로직을 봐야한다. VPN은 받은 캡슐화된 데이터(L3니까 IP+TCP+데이터)를 암호화한다. = 이전에 키교환 과정 필요 암호화한 캡슐화 데이터를 다시 L3까지의 프로토콜을 다시 붙인다.(IP+TCP+암호화:[IP+TCP+데이터]) 즉, 2중 캡슐화를 통해, 프로토콜을 통해 정상적인 통신 과정을 진행할 수 있게 하고(암호화하면 패킷의 프로토콜이 인식이 안됨), 중간에서 열어봤자 암호화 되서 볼 수 없게 하는 것이 VPN!

📌 근황

일단 지금은 시험기간이다. 4월 3째주... 시대생으로 들어온지 2개월 만에, 팀 협업으로 1차 프로젝트는 마무리 했다. 이 글을 차피 비공개 처리할 것이기 때문에 솔직하게 풀어볼 예정이다! 또 시대생 TF에 참여할 수 있게 되었고, 잘만 된다면, 내가 원하던 로직적으로 복잡한 프로젝트가 되지 않을까 싶다. 채팅 서비스에 관심 있던 MSA까지 할 수 있었으면 배우는게 많아서 너무 좋을 것 같다. 수아 및 용현이랑 CS 스터디를 결성했고, 시대생에서 서버 이전 프로젝트에 참여하게 되었다

📌 향후 블로그 방향성 및 계획

CS 스터디를 시작하면서 배울 내용들을 노션에 정리하기 보다는 블로그에 정리하는게 조금 나중에 더 유용하지 않을까 생각했다. 블로그를 공개해야하기 때문에 ssul 태그 글들을 비공개 처리하는 것과 동시에, 내가 이전에 공부하면서 적었던 글들을 읽어 보았다. 내용정리가 끝인 느낌.. 읽어봐도, 크게 도움되는 느낌을 글이 아니었다. (결국 ssul만 열심히 적고, 잘 읽히고 ㅋㅋㅋㅋ, 기술 내용은 이전에 정리 한번 해서 많이 없기도 한 듯) 때문에 그냥 내용 정리보다는 내 언어로 다시 적는 느낌으로 대화체를 사용해서 적어보고자 한다. 임시글로 저장해 놓은 TF 진행하면서 배운 내용들도 최대한 빠르게 올려볼 생각이고! 내가 다시 읽었을 때, 까먹었어도 다시 이해를 할 수 있는 수준이 되는 것을 목표로 정리해볼 것이다. 설치나, 기본 이론 같은 부분은 어쩔 수 없이 줄글이 되겠지만, 배운 내용들과 고민했던 것들 위주로 정리해 보겠다.

📖 리팩토링 프로젝트 (refactor)

• 일단 진행하지 않을 것이다.

애초에 코틀린으로 구조를 생각하면서 짜게 되는 법을 배우면 의미가 없어지기도 했고, tiggle을 수정하는 것이 매우 큰 투자가 필요함이 당연한데, 그 정도의 결과가 나오는지 의문점이 들고, 시대생 프로젝트(TF 뿐 아니라, 서버이전 등)를 하면서 동시에 진행하는 것은 무리다. 결국 서버이전 자체가 리팩토링 프로젝트의 핵심이었던 CI/CD쪽을 해볼 수 있어 일단 멈추고, 이후에 다시 진행하는게 맞지 않을까?

📖 TF 과정 중 에러나 사용 기술 관련 (t-shoot)

• 최대한 대화체를 사용해서 이해하기 쉽도록

처음 봐도 이해가 쉽도록, 내가 이해한 내용들을 풀어서 설명해 보려한다. 솔직히 막막한 부분들도 있긴 한데, 일단 써보고! 너무 답이 없다 싶으면 어쩌겠냐.. 그냥 정리해봐야지

📖 CS-study (cs-network)

• 일단 네트워크로 시작 다른 친구들이 어떻게 정리할지는 모르겠으나, 나는 대화체로 적어볼 예정 안된다 그럼 바꾸지 뭐

📖 CI/CD 관련 (cicd)

• 시대생 서버 이전 하면서, 공부한 내용들 정리해보기

일단 자유롭게 쓸 수있는 초고성능 컴퓨터 생겼으니까, 이전에 생각했던 것들 여러 노드 가지고 이것 저것 해보다 보면 뭐라도 늘지 않을까 ㅋㅋㅋ

📖 Entity

Constructors는 생략이 가능하지만, *찾고자하는 entity에 작성하고, ctrl 클릭을 하게 되면 *

• 기존에는 모든 User 관련 모든 사용처가 뜨지만

  
  

• Entity를 사용한 곳만 찾아낼 수 있다.

📌 이해를 위해 알아야 할 기본 개념

📖 1. 레퍼런스 객체

- 클래스의 객체를 가리키는 값 (변수?와 유사) => 아래 코드의 person1

class Person(val name: String, val age: Int)

val person1 = Person("Alice", 30)

📖 2. 참조(리플렉션) 연산자 (::)

- class, method, property 등을 참조해오는 연산자

• JAVA는 .을 통해서

1. 어떠한 클래스의 객체를 생성
2. 그 객체의 속성이나 메소드를 참조가 아닌 직접 접근
   

• kotlin에서는 .을 통해서 객체 본연의 값을 가져오는 것도 가능하지만 ::을 통해서

1. 참조를 통한 각 개별 값 접근을 반복문을 통한 수정이 아닌 전체 데이터 변경

   fun main() {
    val names = listOf("Alice", "Bob", "Charlie")
    val upperCaseNames = names.map(String::toUpperCase) // 메서드 참조 사용
    println(upperCaseNames) // [ALICE, BOB, CHARLIE]
   }

2. 정확한 속성이나 메소드 이름을 모를 때도 가능 => 이것이 핵심
   

📌 문제 상황

📖 Java에서 Kotlin으로 Entity를 수정 하던 중 JPA repository의 annotation을 사용하는 과정에서 에러가 발생

• intellij에서는 추가 construcor와 getter/setter의 추가 생성 요청 (but 해결 X)

  Caused by: java.lang.ClassNotFoundException: kotlin.reflect.full.KClasses

📌 해결 방안

📖 리플렉션 관련 라이브러리 추가

implementation "org.jetbrains.kotlin:kotlin-reflect:{kotlin_version}"

📌 원리

📖 1. JVM

*중요 !!! : JVM의 클래스 로더는 클래스 실행 시키기 전에 클래스가 필요로 하는 메모리 및 자원을 할당 *

• 그럼 어떻게? 클래스가 실행 되지도 않았는데 어떤 필드, 메서드 등이 있을 지 알고 할당 => Reflection : 런타임에 프로그램의 클래스를 조사하기 위해 사용되는 기술 => Reflection을 이용하기 위해서 사용하는 객체 = 레퍼런스 객체

Class<?> aClass = Class.forName("클래스 파일 위치")
aClass.getDeclaredFields()
aClass.getDeclaredAnnotations()

이처럼 declared를 이용해서 class 파일명만 알아도, 내부를 분석할 수 있도록 작동

📖 2. JPA repository와 같은 라이브러리

동일하게 어떤 클래스든 간에 작동해야 하기 때문에

*- @Entity라던가, 어떤 속성이 @Id가 붙어 있는지 확인해야하는데 내부 클래스나, 속성 정보 없이 해야하기 때문에 Reflect이용 *

📖 3. java는 reflect가 기본 라이브러리 / kotlin에서는 X

• 아마 이러한 부분을 해결하기 위해, 가상 객체를 생성하여, reflect를 사용하지 않는 복잡한 방법이 있어, intellij에서는 생성자를 추가로 생성해보라고 하지 않았을까?
• 이 부분은 정확하지 않음
  

📌 이후에 할 추가 공부

https://everyday-develop-myself.tistory.com/319

• reflection은 generic과 변성
• in out과 kClass 등...

📌 Junit5 in Kopring

📖 1. Annotation

• @Test : 테스트 메소드 지정
• @BeforeEach : 각 테스트가 수행되기 전 실행
• @AfterEach : 각 테스트가 수행된 후 실행
• @BeforeAll : 테스트를 실행하기 전 최초 한번만 실행
• @AfterAll : 테스트를 실행한 후 최초 한번만 실행

=> @BeforeAll과 @AfterAll은 전체에 영향을 주므로 Java에서는 static설정 Kotlin에서는 conpanion object로 선언된 곳에 사용 (@JvmStatic 필수)

class JunitTest {
    companion object {
        @JvmStatic
        @BeforeAll
        fun beforeAll(): Unit {

        }
    }

    @BeforeEach
    fun beforeEach() {}

    @Test
    fun test1(){

    }

    @Test
    fun test2(){

    }

}

📖 2. AssertThat : 단언문

• import시 AssertProvider로

@Test가 적힌 메소드 (given / when / then) 중 then에 사용하며, 잘못된 값이 들어왔을 때, 예상 값과 실제 값을 비교 가능

//then
        assertThat(calculator.number).isEqualTo(7)

• assertThat(A) A는 대상 값

  assertThrows<에러명>으로 에러 검출 및 메세지 확인 가능

  val message = assertThrows<IllegalArgumentException> { 
  function1() }.message 
    assertThat(message).isEqualTo("잘못된 값이 들어왔습니다")
  
  //context Object 활용 => 기억안나면 Kotlin 기본 문법
  assertThrows<IllegalArgumentException> { function1() }.apply {
     assertThat(message).isEqualTo("잘못된 값이 들어왔습니다")
  }

  
  

• isEqualTo(B) B는 기대 값

  • .isEqualTo
  • .isTrue/ isFalse
  • .hasSize
  • .extracting("name").containsExactlyInAnyOrder("LEE", "Park") 리스트 값의 name이라는 파라미터 값이 맞는지 (순서 상관 X)
  • .extracting("name").containsExactly("LEE", "Park") 리스트 값의 name이라는 파라미터 값이 맞는지 (순서 상관 O)

📖 3. Spring에서의 각 계층 테스트

• Controller : 응답받는 JSON 및 Http 위주의 검증 (@SpringBootTest)
• Domain(순수한 자바 객체) : 기존의 class 테스트
• Service, Repository : 스프링 빈을 활용한 데이터 위주의 테스트 (@SpringBootTest)

0) Java Code -> test Kotlin (Java코드 베이스로 kotlin 테스트를 구현할 경우)

• @Autowired를 통해 Service와 Repository를 의존성 주입

• 각 테스트에 @DisplayName을 통해서 이름 지정 가능

• UserCreateRequest("lee", null)를 사용하기 위해서는 생성자 필수

  @SpringBootTest
  class UserServiceTest @Autowired constructor(
    private val userService: UserService,
    private val userRepository: UserRepository,
    )
  {
    @Test
    @DisplayName("유저 등록이 정상 작동 한다.")
    fun saveUserTest(){
        //given
        val request = UserCreateRequest("lee", null)
  
        //when
        userService.saveUser(request)
  
        //then
        val result = userRepository.findAll()
        assertThat(result).hasSize(1)
        assertThat(result[0].name).isEqualTo("lee")
        assertThat(result[0].age).isNull()
    }
  

}

- null일 경우 kotlin에서는 null이 가능한지 확인이 안되므로, Java 엔티티의 getter에 @Nullable, @NotNull 필요
```java
@Entity
public class User {

  @Id
  @GeneratedValue(strategy = IDENTITY)
  private Long id;

  @Column(nullable = false)
  private String name;

  private Integer age;

  @NotNull
  public String getName() {
    return name;
  }

  @Nullable
  public Integer getAge() {
    return age;
  }

중요! 동일한 스프링 컨텍스트(H2 database)를 공유하기 때문에 연속된 테스트 과정에서 각 테스트가 정상적이어도 문제가 발생할 수 있다

따라서 각 테스트 후에 AfterEach로 db초기화 필요

@AfterEach
    fun clean() {
        userRepository.deleteAll()
    }

📖 4. 전체 테스트 진행

Intellij에서 gradle -> verification -> test

📌 기존 자바 코드가 어떤식으로 바뀌는 지!

참고 : https://jinjinyang.tistory.com/66

📖 1. 함수

1. 선언 방식 => fun 함수명 (매개변수명 : 타입) : 반환타입

기본 선언

fun sum(a: Int, b: Int):Int = a+b { }

• return을 따로 지정할 필요가 없음 (return a+b와 동일)

반환 값이 void

fun sum2(a: Int, b: Int):Unit { }

** 코틀린 함수의 장점 => 매개값이 다른 동일한 함수를 계속 만들 필요 X**

• 디폴트 파라미터 선언
• 파라미터 지정
• 특정 인자만 값 세팅 가능

📖 2. 변수와 상수

1. 선언 방식 => var/val 변수명 : 타입(대문자) = 값

var : 변수(가변값)

val myName : String = "ashd"

val : 상수(불변값)

var myAge : Int = 20

2. 출력 => $활용

$변수

val number = 20
println("Please give me $number dollors")

${수식}

val number = 20
println("I only have ${if (number <10 ) number else 10} dollor")

📖 3. 클래스

0. 기본 형태 (생성자가 필요치 않음)

Java

@Getter
@Setter
@AllArgsConstructor
public class Person {
    private String name;
    private int age;
    private boolean isMarred;
}

Kotlin

class Person(val name: String, val age: Int, val isMarried: Boolean)

1. 자바와 달리 field 선언만 하고 Getter, Setter를 사용하지 않음

• 간결한 선언
• 명칭을 통한 getter/setter

  fun main (args: Array<String>) {
    val person = Person("ashd", 20, false)
    println(person.isMarried());
  }

  ### decompile(자바로 어떻게 되는지) => shiftX2(info창) - Bytecode Viewer

public final class PersonKt {
    public static final void main() {
      Person person = new Person("ashd", 20, false);
      String var1 = person.getName();
      System.out.println(var1);
      int var2 = person.getAge();
      System.out.println(var2);
      boolean var3 = person.isMarried();
      System.out.println(var3);
   }

2. Custom Getter/Setter

• get() / set()
• 변수 선언 후 getter/setter의 결정 방법을 선언

  class Rectangle (val height: Int, val width: Int) {
    val isSquare:Boolean
        get(){
            return height == width
        }
  }

  하나의 파일에 여러 클래스와 함수, 최상위 변수를 선언 가능 + 장점

코틀린에서 편리해서 자주 활용되는 부분임 결합도가 높은 클래스, 유사한 클래스, enum 클래스 등 한곳에 모아 놓으면 관리와 사용이 편리해짐

📖 4. when(조건문) + enum

0. Enum (public enum -> enum class)

enum class Color(val r: Int, val g: Int, val b: Int){
    RED(255, 0, 0),
    ORANGE(255, 166, 0),
    YELLOW(255, 255, 0),
    GREEN(0, 255, 0);// 아래 함수와 구분을 위해서 세미콜론 추가

    fun rgb() = (r * 256 + g) *256 + b
}

1. When은 Swtich문을 대체한다 (Enum활용이 필수)

• 화살표 사용
• 다중 대체가 가능
• else는 사용할 수 있지만, when은 case를 지정하지 않았을 때, 컴파일 단계에서 에러를 찾을 수 있어 수정이 편리

  fun getKoreanColor(color: Color): String =
    when(color) {
        RED, ORANGE -> "빨강 혹은 오렌지"
        YELLOW -> "노랑"
        GREEN -> "녹색"
    }
  }

  2. 인자가 없는 When (Else처리 필수)

  fun mix(c1: Color, c2: Color) =
    //인자가 없는 when의 경우 반드시 else을 정의해야 됨
    when {
        c1 == RED && c2 == YELLOW -> ORANGE
        c1 == YELLOW && c2 == BLUE -> GREEN
        else -> throw RuntimeException()
    }

  3. When을 활용한 TypeCast

  fun printObject(obj: Any): Unit = when(obj){
    is String -> println(obj.lowercase())
    is Duration -> println(obj.nano)
    is LocalDateTime -> println(obj.month)
    else -> println("Unknown type")
  }

  
  

📖 5. 반복문

0. while (java와 동일)

• do-while 사용 가능

1. for (python과 유사)

• a..b는 a<=x<=b와 동일 (첫과 끝을 반드시 포함)
• until을 써도 되지만 쓸모 없음

  fun main(){
    for (i in 1..10){
        println(evenOrOdd(i))
    }
    // 마지막 10 미포함 -> until활용
    // for (i in 1<= until < 100)

2. map

• 컬렉션 함수 존재 mutableMapOf, listOf, mapOf, setOf 사용 가능
• 순환 및 구조 분해 이용 가능 순환 (s.key & s.value) => for (s in students) 구조분해 (num,name) => for ((num, name) in students)

  val students = mutableMapOf<Int, String>()
    students[1] = "lee"
    students[2] = "kim"
    students[3] = "park"

*일반 mapOf는 to를 통해 key, value 선언 (가장 많이 사용) *

val st = mapOf(
        1 to "Jock",
        2 to "Diana",
        3 to "Frost"
    )

📖 6. 예외 처리

1. try catch (new를 사용하지 않음)

• when처럼 반환의 값으로 취급

  fun parse(numberStr: String): Int = try {
    Integer.parseInt(numberStr)
  
    throw IOException("일부로 발생시키는 checked exception")
  } catch (e: IOException) {
    throw RuntimeException("UnChecked exception으로 변환") // 후에 설명할 checked  Exception 처리 방식
  } finally {
    println("무조건 실행되는 코드블록")
  }

중요 @Transactional과 checked Exception

• Checked Exception: 컴파일 타임에 체크되는 예외 = 처리를 해야 코드가 돌아감 Ex) IOException, SQLException, ClassNotFoundException 등

• Unchecked Exception: NullPointerException 같은 작동 중에 발생하는 에러

*Java에서는 @Transcational을 사용하면 unchecked exception이 발생할 경우에만 트랜잭션을 롤백한다. *

= 컴파일 과정에서, reader로 읽을 파일이 존재하는지, 읽기 권한은 있는지 등의 checked Exception이 발생할 수 있는 에러는 찾아서 실행을 막음(이미 걸러짐) => Unchecked Exception이 발생했을 때만 롤백해도 정상적으로 작동

Kotiln에서는 Checked Exception이 없음 즉, @Transcational을 사용하면 checked exception이 발생한 경우 롤백하지 않는다.

= IO Exception과 같은 checked Exception이 발생했을 경우 강제로 unchecked Exception을 던져주거나, 롤백하는 코드가 필요 pstmt1이 실행하는 sql문이 name으로 찾아서 update라면, update가 실패할 가능성 존재

try (PreparedStatement pstmt1 = connection.prepareStatement(sql1);

                // 쿼리 실행 (예외 발생 가능성)
                pstmt1.setString(1,"Bob");
                pstmt1.executeUpdate();

                // 모든 쿼리가 성공적으로 실행되면 커밋
                connection.commit();
            } catch (SQLException e) {
                // 예외 발생 시 롤백
                System.out.println("예외 발생: " + e.getMessage());
                if (connection != null) {
                    try {
                        connection.rollback();
                        System.out.println("트랜잭션 롤백 완료");
                    } catch (SQLException rollbackEx) {
                        System.out.println("롤백 중 오류 발생: " + rollbackEx.getMessage());
                    }
                }
            }

📖 7. 확장 함수 및 확장 프로퍼티

1. 확장 함수 (kotlin은 기본적으로 final)

• kotlin의 함수들은 강제로 Open을 달아주지 않는 이상 상속할 수 없다. (List와 같은 라이브러리 함수의 경우 상속이 불가능)
• 오버라이딩은 불가능 / 오버로딩은 가능
• 기본 형태는 fun 피확장함수명.새확장함수명 ( )

이 코드는 List를 상속받아 generic 데이터를 기준 값으로 정하는 확장 함수

• 참고 : generic은 함수를 선언할 때, 이게 generic함수라는 것을 알려줘야함

  fun <E> List<E>.getHigherThan(num: E): List<E> {
    // 구현....
    return arrayListOf<E>()
  }

중요 : 확장 함수는 정적 바인딩된다!

open class Idol {
    open fun sing() = println("아이돌이 노래를 불러요")
}

class BTS: Idol() {
    override fun sing() = println("BTS가 노래를 불러요")
}

fun Idol.dance() = println("아이돌이 춤을 춰요")
fun BTS.dance() = println("BTS가 춤을 춰요")

fun main() {
    // 부모 타입으로 자식 객체 생성
    val bts: Idol = BTS()
    bts.sing() // BTS가 노래를 불러요
    bts.dance() // 아이돌이 춤을 춰요
}

타입과 객체 : Idol 타입의 변수인 bts는 Idol 클래스 또는 그 자식 클래스인 BTS의 객체를 참조

• sing은 일반 함수이기 때문에 동적바인딩 즉 bts가 처음에는 부모 클래스인 Idol타입이지만 default값으로 자식 클래스인 BTS 객체로 선언될 때를 인식하고 => BTS
• dance는 확장 함수이기 때문에 정적바인딩 되어서, 처음 부모 클래스인 Idol타입으로 인식 => Idol

2. 확장 프로퍼티

• 확장 함수와 유사한 형태로
• 단 일회성
• getter는 필수 / setter는 선택

var StringBuilder.lastChar: Char
    get() = get(length - 1)
    set(value: Char) {
        this.setCharAt(length - 1, value)
    }

fun main() {
    val sb = StringBuilder("Gold")
    sb.lastChar = 'f'
    println(sb) // golf
}

📖 8. 인터페이스와 상속

1. 인터페이스 (반드시 overrride)

• implements나 extends로 구현하지 않고 코틀린에서는 : 으로
• 다중 상속도 동일하게 가능

2. 상속 (반드시 Open으로 선언 필수)

• 메소드도 open으로 선언해야 상속 가능
• 상속받은 메소드(override)는 재상속 가능
• 다중 상속도 동일하게 가능

상속 생성자 선언 방법

• 주 생성자(All args)는 선언부에서 기본으로 생성

• 부 생성자는 construct를 통해 생성하고 :뒤에 this - 다른 생성자, super - 상속 클래스 생성자를 호출

  class Child : Parent{
    private val subName:String
  
    constructor(subName: String):this(subName, "")
  
    constructor(subName:String, firstName: String):super(firstName){
        this.subName = subName
    }
  }

위 코드의 간소화

• subName만 있을 때는 firstName을 ""으로 받으므로 => Default 값으로 변경
• firstName이 존재할 경우 부모 클래스의 생성자 호출

  class Child(val subName:String, firstName: String = "") : Parent(firstName)

📖 9. Sealed(봉인된) class

• 인터페이스와 달리, 클래스로 인식되어서 클래스명()로

  1. 인터페이스를 사용 중에 추가된 클래스가 있을 때

• 추가 클래스가 있을 때, getMessage 함수에서 컴파일 단계에서 에러로 처리되지 않음 => else처리

interface Error

class FileError(val filename:String) : Error

class DatabaseError(val database:Database) : Error

class RedisError(val host:String): Error

enum class Database{
    ORACLE, MYSQL, MARIADB;
}

fun getMassage(error: Error) = when(error){
    is FileError -> "error is fileError ${error.filename}"
    is DatabaseError -> "error is databaseError ${error.database.name}"
    else -> throw IllegalArgumentException("error is unknown")
}

2. sealed class를 사용 중에 추가된 클래스가 있을 때

• RedisError를 추가하면, getMessage2에 RedisError에 대한 처리가 안되어있기 때문에 처리 편리 => enum에서 -> 이용하는 방식과 동일한 원리

  sealed class Error2{
    class FileError(val filename:String) : Error2()
    class DatabaseError(val database:Database) : Error2()
    class RedisError(val host:String): Error2()
  }
  

enum class Database2{ ORACLE, MYSQL, MARIADB; }

fun getMassage2(error: Error2) = when(error){ is Error2.DatabaseError -> "error is databaseError ${error.database.name}" is Error2.FileError -> "error is fileError ${error.filename}" is Error2.RedisError -> "error is redisError ${error.host}" }

<br>

### 📖 10. 활용 (private set / data class / object class)
#### 1. set 제한 (private set)
```kotlin
class Account {
    var balance: long = 0
    private set
}

2. data class (java의 record와 유사)

toString을 쓴 것 처럼 객체 안의 내용을 확인 가능 => 객체 조회시 이름@주소가 아니라, 주 생성자의 값들이 출력됨

• DTO 생성 시 유용
• toString()/equals()/hashCode() 사용 가능

  data class User(val name: String, val age: Int)

3. object 키워드 (싱글톤 패턴)

• object라고만 써야함 (class x )
• 유일 인스턴스가 자동으로 생성

  object NumberUtil {
    fun sum(a:Int, b:Int) = a+b
    fun multiply(a:Int, b:Int) = a*b
  }
  

fun main() { println(NumberUtil.multiply(10 ,2)) }

<br>
- 익명 클래스로 사용 가능

> **참고 : companion Object**

- static 대용으로 사용 가능 (클래스 생성 시 팩토리 생성자 기능)
=> 상수 선언
=> 처음 생성되는 데이터의 나이를 0으로 고정하는 팩토리 생성자
```kotlin
data class Child (val name:String, val age:Int){
    companion object {
        const val MAX_CHILDREN = 4

        fun ofDefaultAge(subName:String):Child{
            return Child(subName, 0)
        }
    }
}

intellij kotlin 프로젝트 Tip

• 생성한 kotlin 폴더가 특수 폴더로 지정되지 않을 때

📌 코딩으로 학습하는 리팩토링

강의를 들으면서 유용한 단축키나 정보를 정리한다!!!

📖 냄새 0. 기초 환경 설정

1. 환경 변수 텍스트 파일로 지정

기초 환경 설정 중 githubBuilder를 이용해 필요한 oauth 정보를 home에서 텍스트 파일로 만들어서 넘겨주도록 구현한 부분이 있는데 file 클래스를 활용하여, 경로를 지정해서 oauth값을 받을 수 있다면, 다른 yml파일의 변수들도 같은 방식으로 사용 가능하지 않을까? => 시간 남을때 조금 더 공부해보자

public static GitHubBuilder fromPropertyFile() throws IOException {
        File homeDir = new File(System.getProperty("user.home"));
        File propertyFile = new File(homeDir, ".github");
        return fromPropertyFile(propertyFile.getPath());
    }

    public static GitHubBuilder fromPropertyFile(String propertyFileName) throws IOException {
        Properties props = new Properties();
        FileInputStream in = null;

        try {
            in = new FileInputStream(propertyFileName);
            props.load(in);
        } finally {
            IOUtils.closeQuietly(in);
        }

        return fromProperties(props);
    }

2. ctrl + -> / ctrl + shift + ->

• ctrl + ->는 단어 단위 이동
• ctrl + shift + ->는 끝과 끝으로 (원래는 END/HOME이지만 keymap에서 편의상 변경)

📖 냄새 1. 이름

• shift + F6 (전체 범위 이름 변경)
• ctrl + F6 (이름 뿐 아니라, 보내는 type, 매개변수 등도) - 선언부만 바뀜

• Method Reference = 람다식을 : : 으로 간략하게

  .forEach(name -> System.out.println(name)); -> .forEach(System.out::println);

• 최신기술 Record (유사 딕셔너리) = Dto를 만들어주면서 자동으로 getter, setter, hashcode(), equals()가 생성

  • hashcode( ) : 객체마다 고유 값
  • equals( ) : 값이 같은지

  public record StudyReview(String reviewer, String review){ }
  

📖 냄새 2. 중복

• shift + F6 (전체 범위 이름 변경)
• ctrl + F6 (이름 뿐 아니라, 보내는 type, 매개변수 등도) - 선언부만 바뀜

📌 Tiggle 리팩토링

지금 생각하는 과정은 다음과 같다. (계속 수정 예정)

2024년 말 목표

1. 자동 배포환경 구성
2. 리팩토링에 관한 공부
3. 스프링 시큐리티에 대한 심화 학습

📖 1. CI/CD 자동 배포를 먼저 구성하고, 서버의 가용율을 확인하면서, 리팩토링을 진행하고자 한다.

jenkins와 argoCD를 활용하고, 백과 프론트를 각각 Blue-Green과 Canary방식을 생각 중이다.

• VM ware로 가상 PC 4대를 만들고 (백엔드 만해도 4대인데, 컴퓨터에서 감당이 될지 모르겠다... AWS는 실수하면 돈이 많이 나갈 위험이 있어서 일단 고려 사항에는 두는게 맞는 것 같다.)
• Master-worker에 쿠버네티스 설치하고 연결까지
• Jenkins랑 ArgoCD설치하고,
• mariadb 설치는 worker에
• Repo하나 파서 Webhook 연결하고
• depolyment.ymal 및 Jenkins pipeline 작성하고
• 결과적으로 Backend를 자동 배포 되게해서 디스코드 알람오게 만드는 것 까지가 1차 목표

📖 2. 리팩토링의 방법에 대한 공부는 조금씩 진행한다.

리팩토링이 말 그대로 더 나은 방향으로 바꾸는 것이지만, 어떤 부분을 어떤 식으로 바꾸는게 맞는지에 대한 명확한 지식이 없다. 아는 것은 중복 코드나, 알아보기 쉬운 변수명 수정 정도? 인프런 강의 : 코딩으로 학습하는 리팩토링 - 백기선 https://www.inflearn.com/course/%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81 이 강의 영상을 매일 조금씩 공부하면서 기본적인 리팩토링의 구조를 알고, 적용해 나가는 방향으로 Tiggle 프로젝트 리팩토링을 진행할 것이다.