담쟁이

[AWS] non www 을 www 으로 redirect 하기 ( Netlify )

imygnam — Wed, 6 Mar 2024 20:36:02 +0900

1. AWS Route53으로 netlify 에 redirect 하기.

2. non www 을 www으로 redirect 하기.

AWS Route53으로 netlify 에 redirect 하기.

www.lolduo.net 을 netlify 에 배포한 https://lolduo.netlify.app/ 으로 redirect 하기 위해서 CNAME 으로 Route53에서 redirect 해주었습니다.

AWS Route53 에서 www.lolduo.net 내역

non www 을 www으로 redirect 하기.

똑같이 CNAME으로 redirect 하면 되지 않을까 생각하였지만 아래와 같은 에러가 발생합니다.

 잘못된 요청입니다.
(InvalidChangeBatch 400: RRSet of type CNAME with DNS name lolduo.net. is not permitted at apex in zone lolduo.net.)

단순히 lolduo.net 만 www.lolduo.net으로 변경할 것이라면 S3의 정적 웹 호스팅을 사용하면 편합니다.

하지만 모든 경로를 포함해서 리다이렉트가 필요했습니다. 예를 들어 lolduo.net/banpick 을 www.lolduo.net/banpick 등이 있습니다.

이를 위해 API Gateway + lambda 로 해결하였습니다.

lambda 생성

export const handler = async (event) => {

    let newLocation = "https://www.lolduo.net" + event.path;
    
    for(let key in event.queryStringParameters) {
        newLocation += (newLocation.includes("?") ? "&" : "?") + key + "=" + event.queryStringParameters[key];
    }
    
    return {
        statusCode: 302,
        headers: { Location: newLocation }
    };
}

단순히 들어온 요청을 새로운 www.lolduo.net으로 변경하여 redirect 해주는 lambda를 생성해줍니다.

그런뒤 생성한 Lambda에 API Gateway 트리거를 추가해주고, 모든 경로를 포함한다는 $default 경로를 추가합니다.

트리거 추가 및 경로 추가

lamdba에 트리거 추가 및 추가한 API Gateway에 경로 생성

API Gateway에서 사용자 지정 도메인 이름을 생성해야 Route53에서 사용이 가능합니다.

사용할 도메인 이름을 생성해주고 API 매핑에서 방금 생성해준 Lambda와 연동된 API Gateway를 추가해줍니다.

사용자 지정 도메인 이름 생성 및 API 매핑

API Gateway 사용자 지정 도메인 이름 생성 및 API 매핑

마지막으로 Route53에서 방금 생성한 사용자 지정 도메인 이름을 매핑해주면 됩니다.

Route53 레코드 생성

Route53의 레코드 생성

[Java] GC 종류별 메모리 상황에 따른 테스트

imygnam — Thu, 8 Feb 2024 17:40:20 +0900

특정 job 에 대해서 메모리를 설정해야하는데 이때 한번 GC를 종류별로 돌려보며 테스트를 해보았습니다.

다만 해당 job이 매우 짧게 끝나기도 하고 메모리를 적게 사용하며 CPU 사용율 등을 자세하게 확인하지 않았기에 가볍게 봐주시면 감사하겠습니다.

테스트 환경은 Java17에 OpenJDK 이며 모니터링으로는 VisualVM + VisualGC 와 jstat을 사용하였습니다.

비교한 GC는 SerialGC, ParallelGC, G1GC, ZGC로 Java17에서 지원하는 GC들 입니다. ShenandoahGC는 테스트하지 않았습니다.

15MB [ -Xms15m -Xmx15m ]

Oracle에서도 100m 이하일때 SerialGC를 추천하는 이유가 확실히 보였습니다. 전체 GC시간이 가장 적은것이 SerialGC 였습니다.

극단적으로 메모리를 낮추어봤을 때 예상외로 G1GC의 성능이 ParallelGC보다 좋았습니다.

ZGC는 OutOfMemory 발생으로 실행조차 되지 않았습니다.

https://docs.oracle.com/en/java/javase/17/gctuning/available-collectors.html#GUID-414C9D95-297E-4EE3-B0D9-36F158A83393

HotSpot Virtual Machine Garbage Collection Tuning Guide

The discussion to this point has been about the serial collector. The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

docs.oracle.com

SerialGC

SerialGC의 VisualVM

jstat -gcutil의 결과

ParallelGC

ParallelGC의 VisualVM

jstat -gcutil의 결과

G1GC

G1GC의 VisualVM

jstat -gcutil의 결과

ZGC

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

50MB [ -Xms50m -Xmx50m ]

Job이 필요로 하는 메모리가 적어서 그런지 여기서부터는 이제 큰 차이를 보이지 않았습니다.

다만 ZGC가 사용가능해진 시점으로 ZGC는 확실히 다른 GC들에 비해 GC 시간이 현저히 적었고 SerialGC는 많았습니다.

평균적으로 사용하는 메모리는 SerialGC와 ParallelGC에 비해 ZGC와 G1GC가 확실히 많이 사용하는 것을 확인할 수 있었습니다.

SerialGC

SerialGC의 VisualVM

jstat -gcutil의 결과

ParallelGC

ParallelGC의 VisualVM

jstat -gcutil의 결과

G1GC

G1GC의 VisualVM

jstat -gcutil의 결과

ZGC

ZGC의 VisualVM

jstat -gcutil의 결과

100MB [ -Xms100m -Xmx100m ]

50m와 크게 다를게 없어보입니다.

ZGC는 여전히 가장 빠른 GC 시간을 보여주며 SerialGC는 여전히 느린 것을 확인할 수 있었습니다.

SerialGC와 ParallelGC의 평균 메모리가 G1GC와 ZGC에 비해 덜 사용하는 것도 확인할 수 있었습니다.

SerialGC

SerialGC의 VisualVM

jstat -gcutil의 결과

ParallelGC

ParallelGC의 VisualVM

jstat -gcutil의 결과

G1GC

G1GC의 VisualVM

jstat -gcutil의 결과

ZGC

ZGC의 VisualVM

jstat -gcutil의 결과

결론

빡빡하게 테스트 환경을 조성하지 않았고, 적은 메모리 만으로도 비교해 보았음에도 각 GC의 특징이 대략적으로나마 보이는 것이 신기하였습니다.

ZGC는 메모리를 확실히 많이 차지하는 한편 압도적인 GC 시간을 보여주었고, SerialGC와 ParallelGC는 상대적으로 적은 메모리 사용률을 보여주며 메모리에 여유가 생기자 ParallelGC가 SerialGC보다 더 나은 성능을 보여주는 것도 확인하였습니다.

더 세밀하게 들어가면 GC 튜닝 등 과정이 들어가겠지만, 이정도 Job에서는 너무 오버엔지니어링 같고 필요성이 느껴지면 그때 학습하여 적용하는 것이 좋겠다는 생각하에 여기서 마무리하려고 합니다.

다만 어떠한 작업을 하고 나서는 반드시 GC에 대해 고민정도는 해야겠다는 생각이 확고하게 드는 테스트였습니다.

https://docs.oracle.com/en/java/javase/17/gctuning/available-collectors.html#GUID-414C9D95-297E-4EE3-B0D9-36F158A83393

HotSpot Virtual Machine Garbage Collection Tuning Guide

The discussion to this point has been about the serial collector. The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

docs.oracle.com

[Java] 버전별 GC 목록 ( OpenJDK )

imygnam — Wed, 7 Feb 2024 17:55:05 +0900

GC 확인 방법
Java8의 GC
Java11의 GC
Java17의 GC
Java21의 GC

GC 확인 방법

현재 Default 로 적용된 GC를 확인하는 방법은 크게 2가지로 다음과 같습니다.

1. 적용중인 Flag를 확인하는 방법

java -XX:+PrintCommandLineFlags -version

해당 명령어로 현재 적용중인 Flag들과 버전을 같이 확인 할 수 있습니다.

Java8에서의 결과

위와 같이 결과가 나오는데 Java8의 경우 ParallelGC를 사용하는 것으로 확인됩니다.

2. 전체 Flag를 확인하는 방법

java -XX:+PrintFlagsFinal -version

해당 명령어로 사용 가능한 Flag들과 현재 그 값들을 확인할 수 있습니다.

grep 명령어와 함께 사용하여 GC 목록들만 뽑아서 확인하면 다음과 같습니다.

Java8 의 GC

Java8 에서의 GC

Java8 의 GC

해당 이미지를 잘 살펴보면 Java8에서는 크게 5가지의 GC를 확인할 수 있습니다.

ConcMarkSweepGC & ParNewGC
G1GC
ParallelGC
ParallelOldGC
SerialGC

Default GC는 ParallelGC인데 자세히 확인해보시면 ParallelGC와 ParallelOldGC가 동시에 활성화 되있는 것을 확인 할 수 있습니다.

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

java

Large Pages Also known as huge pages, large pages are memory pages that are significantly larger than the standard memory page size (which varies depending on the processor and operating system). Large pages optimize processor Translation-Lookaside Buffers

docs.oracle.com

찾은 것이 비록 Oracle 이지만 ParallelGC 옵션은 추가로 설정을 하지 않는 이상 ParallelOldGC 옵션을 활성화 시키며 ParallelOldGC는 ParallelGC를 자동으로 활성화 시킨다고 되어있습니다.

즉 ParallelGC만을 활성화는 가능하지만 ParallelOldGC만 활성화는 불가능합니다.

ParallelGC 설명

또한 ConcMarkSweepGC는 활성화 시 ParNewGC가 자동으로 활성화 되고 역으로도 마찬가지라고 설명이 되어있습니다.

Java11에서의 GC

Java11 의 GC

Java11에서도 5개의 GC가 확인됩니다.

ConcMarkSweepGC
G1GC
ParallelGC
ParallelOldGC
SerialGC

Java11에서는 Default GC가 G1GC이며 ParNewGC가 사라졌습니다.

추가로 Oracle 에서는 ZGC도 확인이 됩니다.

Oracle Java11에서 ZGC

https://docs.oracle.com/en/java/javase/11/gctuning/available-collectors.html#GUID-F215A508-9E58-40B4-90A5-74E29BF3BD3C

HotSpot Virtual Machine Garbage Collection Tuning Guide

The discussion to this point has been about the serial collector. The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

docs.oracle.com

Java17에서의 GC

Java17의 GC

Java17에서부터는 ZGC와 ShenandoahGC가 보이기 시작합니다.

Default GC는 그대로 G1GC이며 ParallelOldGC가 ParallelGC로 병합되어서 따로 존재하지 않습니다.

G1GC
ParallelGC
SerialGC
ShenandoahGC
ZGC

다만 Oracle에서는 ShenandoahGC가 확인되지 않는데 이는 Openjdk 홈페이지에서도 확인이 가능합니다.

ShenandoahGC의 Releases

https://docs.oracle.com/en/java/javase/17/gctuning/available-collectors.html#GUID-F215A508-9E58-40B4-90A5-74E29BF3BD3C

HotSpot Virtual Machine Garbage Collection Tuning Guide

The discussion to this point has been about the serial collector. The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

docs.oracle.com

https://wiki.openjdk.org/display/shenandoah/Main

Main - Main - OpenJDK Wiki

wiki.openjdk.org

Java21에서의 GC

Java21의 GC

Java21에서도 동일하게 5개의 GC가 확인되며 Default GC 또한 동일하게 G1GC입니다.

G1GC
ParallelGC
SerialGC
ShenandoahGC
ZGC

[JAVA] JVM 동작 방식

imygnam — Tue, 6 Feb 2024 20:52:21 +0900

JVM이란
Class Loader
Execution Engine
Runtime Data Areas

JVM이란

JVM은 Java Virtual Machine의 약자로 자바 바이트코드를 실행하는 가상 머신입니다.

자바는 Compile시 자바 Source Code가 바이트코드 ( .class 파일 ) 로 변환되며 이 바이트코드가 JVM에서 실행되는 구조입니다.

JVM 구성도

JVM ( Java Virtual Machine )의 동작 구조를 간단히 설명하면 다음과 같습니다.

Class Loader는 실행할 프로그램의 Class를 Runtime Data Areas에 Load 합니다.
Load 된 Class는 Execution Engine 에 의해 실행됩니다.

Class Loader

Class Loader 구조

Class Loader의 동작 방식을 자세히 보면 다음과 같습니다.

로딩 ( Loading ) : Class Loader는 .class 파일을 JVM의 메모리에 로드합니다.
자세하게는 바이너리 형태의 Class data 가 Method Area에 저장됩니다.
링킹 ( Linking ) : 로드된 Class data는 JVM에서 사용될 수 있도록 링킹 과정을 거치는데 크게 3가지 단계로 이루어집니다.
1. 검증 ( Verification ) : 로드된 Class가 JVM의 안전한 실행을 위반하지 않는지 검사합니다.
  예를들어 형식의 안정성, 액세스 권한 위반 ( private 또는 protected 접근 ) 등을 확인합니다.
2. 준비 ( Preparation ) : Class 변수 ( Static 변수 ) 에 메모리를 할당하고, 기본값으로 초기화 합니다.
  이때 초기화하는 값은 타입에 따른 기본값 ( int의 경우 0 ) 을 할당합니다.
3. 해석 ( Resolution ) : 심볼릭 메모리 레퍼런스를 Method Area에 존재하는 실제 레퍼런스로 교체합니다.
초기화 ( Initialization ) : Class 변수들에 대해 정의된 초기값을 설정합니다. 이 과정에서 정적 초기화 블록이 실행됩니다.

Execution Engine

실행 엔진은 .class 파일의 바이트코드가 Class Loader에 의해 Load된 바이트코드를 기계어로 변환하여 실행하는 역할을 담당합니다.

실행 엔진은 크게 3가지로 구성이 되어있는데 다음과 같습니다.

인터프리터 ( Interpreter ) : 바이트코드를 한 줄씩 읽어서 바로 실행합니다.
JIT ( Just-In-Time ) 컴파일러 : 인터프리터의 단점을 보완하기 위해 도입된 것으로 실행 되는 동안 바이트코드의 핫스팟(HotSpot) 즉 반복적으로 실행되는 코드 부분을 식별하고, 이를 기계어로 변환하여 실행 속도를 향상시키는 것입니다.
변환된 코드는 캐시에 저장되어 있으며 이후 지속적으로 재사용됩니다.
가비지 컬렉터 ( Garbage Collector ) : 프로그램 실행 중에 생성된 객체 중에서 더 이상 참조되지 않는 객체를 자동으로 검출하고, 이를 삭제하여 메모리를 관리합니다.

Runtime Data Areas

Runtime Data Areas 구성도

Runtime Data Area는 Runtime 시에 사용하는 메모리 영역이며 크게 5개로 분류됩니다.

Method Area : 모든 스레드가 공유하는 영역으로, 클래스 정보를 가지고 있습니다.
각 클래스의 구조, 상수 풀, 정적 변수, 바이트코드 등 메타데이터가 저장되어 있습니다.
Heap : 모든 스레드가 공유하는 영역으로, 대부분의 메모리를 차지합니다.
인스턴스 객체 및 배열 등 동적으로 할당된 데이터를 저장합니다. GC ( Garbage Collection ) 이 이 영역에서 발생합니다.
Stack : 각 스레드마다 하나씩 생성되며, 메소드 호출 및 실행을 관리합니다.
각 메소드 호출마다 Frame이 스택에 생성되며 Frame에는 로컬 변수, 결과 등이 담겨있습니다.
메소드가 종료되면 Frame도 사라집니다.
PC Register ( Program Counter Register ) : 각 스레드마다 하나씩 생성되며, 현재 실행중인 JVM 명령의 주소를 관리합니다. 이로써 각 스레드가 현재 어느 명령어를 실행중인지 알 수 있습니다.
Native Method Stack : 각 스레드마다 하나씩 생성되며, Java가 아닌 다른 언어로 작성된 메소드를 관리합니다.

[LOL-DUO] Lamdba 로 데이터를 크롤링해 RDS 에 데이터 저장하기.

imygnam — Sat, 6 Jan 2024 16:24:42 +0900

1. 목표

2. 아키텍처 설계 과정

2.1 Lambda로 진행한 이유

2.2 Lambda가 2개로 나뉘어진 이유

2.3 JS로 진행한 이유

3. 개발 과정

3.1 VPC 내부에 Lambda 생성하기.

3.2 Lambda 함수 개발 ( JS )

1. 목표

1. FreeTier 내에서 가능하도록 구현. ( 최소한의 비용 )

2. Riot 데이터를 가져와 가공하여 RDS에 저장하기 및 내 서버 상태 체크.

3. 매 1시간 마다 돌며 결과를 Slack 으로 제공.

매 1시간 마다 Server의 상태 체크 등 정보를 가져와 Slack으로 알려주는 기능이 필요했습니다.

또한 주기적으로 Riot Data ( Version ) 등을 가져와 변경사항이 있다면 Database에 저장하고 알려주는 기능이 필요했습니다.

따라서 이를 묶어서 하나의 Job으로 만들고자 했고 Lambda가 적격이라 생각해 Lambda로 진행하였습니다.

2. 아키텍처 설계 과정

전체 아키텍처

2.1 Lambda로 진행한 이유

기존에 돌고 있는 Job들이 존재해서 그곳에 추가를 하는 방법도 있었지만 해당 Job들은 Server와 동일한 EC2에서 동작하고 있기에 Server 가 죽는 상황이면 Job들도 죽는 상황일 가능성이 매우 높습니다.

Server의 상태를 지속적으로 알려주는 Job이 죽는다면 상태를 알 방법이 없기에 Server와 분리할 필요가 있다고 판단하였고, 매시간 단기간만 동작하면 되기에 Lambda를 선택하였습니다.

2.2 Lambda가 2개로 나뉘어진 이유

Lambda는 VPC 내에 생성한다면 Public Ip를 할당 받지 않습니다. 따라서 외부에 http 요청을 보낸다면 수신하지 못합니다.

하지만 RDS와 EC2 Server는 Private하게 관리를 해야합니다. 따라서 RDS에 정보를 저장하고 EC2 Server 정보를 가져오려면 VPC 내부에 Lambda를 띄워주어야 하는데, 이러면 해당 Lambda는 Riot 정보를 가져오지 못합니다.

이에 Riot 정보를 가져오고 Slack으로 Webhook을 날려주는 Lambda와 DB에 정보를 저장하고 Server 상태를 가져오는 VPC 내부의 Lambda를 각각 생성하여 역할을 나누었습니다.

물론 VPC 내부에 Nat Gateway를 설치해서 해당 Lambda가 Riot 정보까지 가져오도록 할 수 있었지만 Nat Gateway는 비용이 발생합니다. 1번 목표를 위해서 해당 방식보다는 Lambda를 2개로 나누는 것이 좋다고 판단하였습니다.

VPC 내부에서 동작하는 Lambda는 API Gateway와 연동되어 요청을 받으면 해당 정보를 DB에 저장, Server 정보를 가져와 반환해주는 API 형태로 만들었습니다. 최소한의 보안을 위해 특정 key값을 설정하였고, 해당 key가 아닌 요청은 무시하도록 설계하였습니다.

VPC 외부에서 동작하는 Lambda는 API Gateway가 필요하지 않는데, 이는 EventBridge가 1시간마다 동작시켜주면 되고 값을 반환할 필요가 없기 때문입니다.

특정 key가 아니라면 다음과 같이 400 Bad Request를 반환합니다.

2.3 JS로 진행한 이유

Riot 에서 제공하는 데이터가 Json 형태이기에 JS로 다루기도 편할 뿐더러 JS가 Lambda의 Cold Start Time도 낮은 편에 속해있기에 JS로 선택하였습니다.

https://mikhail.io/serverless/coldstarts/aws/languages/

AWS Lambda: Cold Start Duration per Language

The following chart shows the typical range of cold starts in AWS Lambda, broken down per language. The darker ranges are the most common 67% of durations, and lighter ranges include 95%.

mikhail.io

3. 개발 과정

3.1 VPC 내부에 Lambda 생성하기.

Lambda 함수와 역할

Lambda를 VPC 내부에 띄우려면 AWSLambdaVPCAccessExecutionRole 권한이 필요합니다.

해당 권한은 Lamdba에 부여된 역할에서 권한 추가를 해주면 됩니다.

그런뒤 다시 구성에서 VPC에 들어가 배포할 VPC로 편집해주면 해당 VPC로 Lambda가 배포됩니다.

API Gateway는 트리거 추가를 통해 손쉽게 부착할 수 있습니다. EventBridge 또한 마찬가지입니다.

EventBridge의 Cron 표현식 사용법은 다음과 같습니다.

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html

Cron expressions reference - Amazon EventBridge

If you use a '#' character, you can define only one expression in the day-of-week field. For example, "3#1,6#3" is not valid because it is interpreted as two expressions.

docs.aws.amazon.com

3.2 Lambda 함수 개발 ( JS )

Lambda는 index.handler를 실행합니다.

handler에 input 또한 전달해주기 때문에 API Gateway를 통해 들어온 정보를 사용할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/nodejs-handler.html

AWS Lambda 함수 핸들러(Node.js) - AWS Lambda

AWS Lambda 함수 핸들러(Node.js) Lambda 함수의 핸들러는 이벤트를 처리하는 함수 코드의 메서드입니다. 함수가 호출되면 Lambda는 핸들러 메서드를 실행합니다. 함수는 핸들러가 응답을 반환하거나 종

docs.aws.amazon.com

따라서 API Gateway를 사용하는 Lambda의 코드는 다음과 같이 구성하였습니다.

기본적으로 개발은 local에서 진행 후 zip으로 node_modules와 함께 파일들을 묶어 올리는 형태로 진행하였습니다.

// lambda 코드 
class app {
    async start() {
        // logic
    }
}
export const handler = async (event, context) => {

    //key check 과정 진행
	
    let body = JSON.parse(event.body); // body parse;
    let result = await new app().start(body.info, ...); // db 저장 및 server 정보 획득
    return {
          statusCode: 200,
          body: JSON.stringify(result),
    };
}

쿠키 ( Cookie ), 세션 ( Session )

imygnam — Fri, 5 Jan 2024 10:31:32 +0900

쿠키와 세션은 웹 통신을 함에 있어 사용되는 개념으로, 사용자의 웹 브라우저와 웹 서버간의 상태 정보를 관리하고 유지하는데 사용됩니다.

웹 통신은 기본적으로 HTTP 프로토콜을 사용하는데, Stateless 환경이기 때문에 상태 정보를 가지고 있을 수 없습니다.

이를 보완하기 위해 사용되는 것이 쿠키와 세션입니다.

이 둘의 공통점으로는 사용자의 정보를 저장하여 사용한다는 점입니다.

매번 인증 등을 진행하지 않고 사용자 정보를 제공한다는 점에서 장점이지만 보안을 신경써야한다는 점이 따라붙습니다.

이 둘의 가장 큰 차이점은 쿠키는 클라이언트 쪽에서 관리가 되며, 세션은 서버 쪽에서 관리가 된다는 점입니다.

이로인해 보안은 세션이 조금 더 좋으며 쿠키를 사용할 때에는 암호화 등을 진행하는 것이 좋습니다.

1. 쿠키 ( Cookie )

쿠키는 클라이언트 ( 웹 브라우저 ) 에 저장되는 작은 데이터입니다.

클라이언트에 저장되므로 서버에 의존하지 않고 정보를 유지할 수 있습니다.

이름(key), 값(value), 만료일, 경로 등의 정보를 담고 있으며 도메인당 최대 20개를 저장할 수 있습니다.

2. 세션 ( Session )

세션은 서버에 저장하는 쿠키라고 생각하면 됩니다.

보통 쿠키와 함께 사용되지만 세션 ID를 서버에 전송할 수 만 있다면 쿠키가 아니어도 상관없습니다.

세션 ID를 통해 데이터를 관리하며 보통 레디스 같은 메모리 DB를 통해 사용합니다.

[Java] Java version 별 차이 ( 7, 8, 9, 11 )

imygnam — Tue, 12 Dec 2023 23:18:16 +0900

java 7 - 다이아몬드 연산자 지원, switch 문에서 String 사용 가능

java 8 - LTS 버전, Default Method, 람다 표현식, 함수형 Method, Optional 구조체, java.time 패키지, Stream API, GC 개선

java 9 - Java Platform Module System ( jigsaw project ), G1 GC, HTTP/2

java 11 - LTS 버전, HTTP/2 강화, 람다 표현식에 로컬 변수 타입 추론 추가

java 7

Java 7 부터 제네렉에서 사용하는 <> 오퍼레이터 ( 다이아몬드 연산자 ) 를 지원합니다.

다이아몬드 연산자를 사용하면 코드를 간결하게 만들고 가독성을 향상시킬 수 있습니다.

List<String> list = new ArrayList<String>(); // jdk 7 이전
List<String> list = new ArrayList<>(); // jdk 7 이후

switch 문에서 String 사용 가능

기존에는 원시 자료형 또는 Enum 자료형만 사용 가능했지만 jdk 7 이후로는 String도 사용가능합니다.

java 8

LTS 버전 입니다. 8 버전에서 큰 변화가 일어났습니다.

1. 인터페이스 ( interface ) 에서 Default Method

본래 인터페이스에서는 메서드의 정의만 가능하고 구현은 불가능하였습니다. 하지만 jdk 8 이후부터는 default 메서드가 생겨났으며 기존 메서드와는 다르게 인터페이스에서 구현이 가능합니다.

이로서 얻는 이득으로 가장 큰 것은 역호환성 유지입니다. 본래 기존 인터페이스에 새로운 메서드를 추가하려고 한다면 해당 인터페이스를 사용하는 다른 프로젝트와의 호환성 문제가 발생할 수 있습니다. 이를 default 메서드 사용을 통해 해결 할 수 있습니다.

2. 람다 표현식, 함수형 인터페이스

람다 표현식은 간결하게 익명 함수를 정의하고 전달하는 방식입니다.

람다 표현식은 주로 함수형 인터페이스에서 사용되는데 함수형 인터페이스란 추상 메서드가 오직 하나인 인터페이스를 의미합니다. 따라서 default 메서드 또는 static 메서드가 여러개여도 상관이 없습니다.

3. Optional 구조체

기존에 NullPointerException 이슈를 효율적으로 대응하기 위해 Optional 구조체가 추가되었습니다.

4. java.time 패키지

기존의 java.util.Date 와 java.util.Calender 는 일관성, 정확성, 타임존 등의 문제점을 가지고 있었습니다. 이를 java.time 패키지 추가로 해결하였습니다.

5. Stream API

데이터를 처리하고 가공하는 데 편리한 Stream API 가 jdk 8 부터 도입되었습니다. Stream을 이용하면 코드를 간결하고 가독성 있게 작성하면서도 손쉽게 병렬 처리 작업을 할 수 있습니다.

6. GC 성능 개선

java 8 이전에는 PermGen 이라는 메모리 영역이 존재하였는데 클래스와 메타데이터 ( 메서드, 필드, 주석 등 ) 을 저장하는 공간이었습니다. 다만 문제는 이것이 고정된 크기여서 클래스 및 메타데이터의 크기가 동적으로 변화하더라도 확장 등이 일어나지 않았습니다. 이를 해결하기 위해 PermGen 영역이 삭제되고 Metaspace 영역 ( Natvice Memory )이 새로 생겨났으며 GC 대상이 되도록 변경하였습니다.

java 9

1. Java Platform Module System ( jigsaw project )

기존에는 의존성 등이 명시적으로 정의되지 않았기에 클래스, 버전 충돌 등 문제가 있었습니다. 이를 해결하기 위해 도입된 프로젝트로 특징은 다음과 같습니다.

- 모듈화

애플리케이션을 독립적인 모듈로 나누고, 각 모듈은 자체적으로 의존성을 관리합니다.

- 의존성 관리

각 모듈은 의존성을 명시적으로 정의하고, 컴파일 타임 및 런타임에서 이러한 의존성을 체크합니다.

2. G1 GC

기본 GC가 Parallel GC 에서 G1 GC 로 변경 되었습니다.

3. HTTP/2 지원

java 9 에서 HTTP/2 프로토콜을 지원합니다.

java 11

LTS 버전입니다.

1. HTTP/2 강화

java 11에서 HTTP/2 지원이 강화되었습니다.

2. 람다 표현식에서 로컬 변수 타입 추론 ( var )

java 11에서 로컬 변수 타입 추론을 지원하는 var 키워드가 도입되었습니다.

[TypeScript] Type Compatibility ( 타입 호환성 )

imygnam — Sat, 9 Dec 2023 23:02:28 +0900

타입 호환성이란?

두 가지 타입 간에 비교를 통해 값이 할당 가능한지 여부를 나타내는 것 입니다. 즉 다른 타입이 해당 타입안에 들어올 수 있는지 판단합니다.

TypeScript의 타입 호환성은 명목적 타이핑 ( nominal typing )이 아닌 구조적 서브 타이핑 ( subtyping ) 을 기반으로 합니다.

구조적 타이핑이란 오직 맴버만으로 타입을 확인하는 방식입니다.

interface test1 {
    test: string;
}

class test2 {
    test: string;
}

let test3: test1;

test3 = new test2(); // 맴버가 같기에 가능합니다.

함수의 비교

let first = (test: string) => "test";
let second = (test: string, test2: string) => "test";

second = first; // OK
first = second; // Error

함수의 비교에서는 매개변수를 서로 비교합니다.

second는 first의 모든 매개변수를 가지고 있기에 호환이 가능하지만 first는 second의 test2 를 가지고 있지 않기에 에러를 반환합니다.

열거형의 비교

enum Test1 {
    A,
    B,
    C,
}

enum Test2 {
    A = 1,
    B,
    C,
}

let test = Test1.A;
test = Test1.B; // OK
test = Test2.A; // Error

열거형은 단순하게 다른 열거형 타입의 열거형과는 호환되지 않습니다. 다만 같은 열거형 내에서는 호환이 가능합니다.

클래스의 비교

class Test1 {
    test: string;
    testFunc() {
        console.log("test");
    }

    constructor(test1: string, test2: string) {
        this.test = test1;
    }
}

class Test2 {
    test: string;
    static test2: string;
    testFunc() {
        console.log("test");
    }

    constructor(test1: string) {
        this.test = test1;
    }
}

let firstTest: Test1;
let secondTest: Test2;

firstTest = secondTest; // OK
secondTest = firstTest; // OK

클래스 타입의 비교는 오직 인스턴스의 맴버만 비교를 진행합니다.

즉 정적 맴버 ( static ) 과 생성자 ( constructor ) 는 호환성에 영향을 주지 않습니다.

제네릭의 비교

interface Test<T> {}
let test1: Test<string>;
let test2: Test<number>;

test1 = test2; // OK
test2 = test1; // OK



interface Test<T> {
    test: T;
}
let test1: Test<string>;
let test2: Test<number>;

test1 = test2; // Error
test2 = test1; // Error

제네릭 타입에서 중요한 것은 결국 결과 타입입니다. 들어가는 Type이 중요한 것이 아닌 결과 인자를 비교합니다.

따라서 처음 호환은 전부 가능하지만 두번째부터는 불가능합니다.

Freshness ( 신선도 ) 란

type Test = {
    name: string;
    age: number;
}

function testFunction(test: Test) {
    console.log(test.name);
}

let testInput = {
    name: 'test',
    age: 10,
    test: 'test'
}

testFunction(testInput); // OK
testFunction({ name: 'test', age: 10 }); // OK
testFunction({ name: 'test', age: 10, test: 'test' }); // Error

TypeScript는 신선도라는 개념을 제공하는데, 모든 object literal 은 초기에 "fresh" 로 간주합니다.

다만 type assertion ( 타입 단언 )을 하거나, 타입 추론에 의해 object literal 의 타입이 확장되면 "fresh" 가 사라집니다.

"fresh" 상태에서는 타입호환을 허용하지 않습니다. 그렇기에 위와 같은 경우에서 마지막에는 Error가 발생합니다.

[JavaScript] Object VS Map ( 성능 비교 )

imygnam — Sat, 2 Dec 2023 23:07:21 +0900

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Map

Map - JavaScript | MDN

Map 객체는 키-값 쌍과 키의 원래 삽입 순서를 기억합니다. 모든 값(객체 및 원시 값 모두)은 키 또는 값으로 사용될 수 있습니다.

developer.mozilla.org

Object

키를 문자열 또는 심볼로만 가질 수 있는 구조입니다. 위 링크에서도 나와있지만 Object는 역사적으로 Map으로 사용되어왔습니다.

Map

key, value 형태로 저장 가능한 자료구조로써 빠른 검색 등에 사용합니다.

Object와는 다르게 키의 데이터 유형에 제약이 없습니다.

Map은 Object를 상속하여 사용합니다. 하지만 당연하게도 Object는 Map을 상속하지는 않습니다.

다만 여기서 조금 주의해서 보아야 할 것은 Map에서 키는 삽입한 순서대로 정렬하여 가지고 있다는 점입니다.

const obj = {};
const map = new Map();
console.log(map instanceof Object); // true
console.log(obj instanceof Map); // false

따라서 단순 생각하기에는 Object나 Map이 성능면에서 비슷할 것이라고 생각하겠지만 실상은 다릅니다.

위 링크에서도 성능 면에서 키-값 쌍의 빈번한 추가 및 제거와 관련된 상황에서 성능이 좀 더 좋습니다. 라고 이야기하고 있습니다.

실제로 그러한지 테스트를 해보겠습니다.

// random array of 1000000 numbers
let arr = new Array(1000000);
for (let i = 0; i < arr.length; i++) {
    arr[i] = Math.random() * 1000;
}
console.log("테스트 시작");

// let arr = new Array(1000000);
// for (let i = 0; i < arr.length; i++) {
//     arr[i] = "key" + Math.floor(Math.random() * arr.length);
// }
// console.log("문자 테스트 시작");

// let arr = new Array(1000000);
// for (let i = 0; i < arr.length; i++) {
//     arr[i] = Symbol(Math.random());
// }
// console.log("심볼 테스트 시작");

const startTime = Date.now();
let obj = {};
for (let i = 0; i < arr.length; i++) {
    obj[arr[i]] = arr[i];
}
const endTime = Date.now();
console.log(`object 삽입 시간: ${endTime - startTime}ms`);

const startTime2 = Date.now();
let map = new Map();
for (let i = 0; i < arr.length; i++) {
    map.set(arr[i], arr[i]);
}
const endTime2 = Date.now();
console.log(`map 삽입 시간: ${endTime2 - startTime2}ms`);

const startTime3 = Date.now();
for (let i = 0; i < arr.length; i++) {
    let a = obj[arr[i]];
}
const endTime3 = Date.now();
console.log(`object 검색 시간: ${endTime3 - startTime3}ms`);

const startTime4 = Date.now();
for (let i = 0; i < arr.length; i++) {
    let a = map.get(arr[i]);
}
const endTime4 = Date.now();

console.log(`map 검색 시간: ${endTime4 - startTime4}ms`);

각각 숫자와 문자, 심볼로 테스트 했을 때 출력된 시간입니다.

결과는 예상대로 Map이 훨씬 빠르게 나왔습니다. 숫자의 경우 삽입은 약 3.5배정도 차이를 보였으며 검색의 경우에는 25배까지 차이가 나는 것이 보였습니다. 이는 숫자의 경우 문자로 변경하는 작업이 들어가는 Object의 특성이 있기에 생기는 문제로 보입니다.

문자의 경우에는 차이가 조금 덜 했습니다. 삽입의 경우 약 2.5배, 검색의 경우에는 4배정도 차이를 보였습니다.

심볼의 경우에는 더 좁혀졌는데, 삽입의 경우 약 1.3배, 검색의 경우에는 동일하게 4배정도 차이를 보였습니다.

헌데 코드를 잘 보시면 알겠지만 이는 삽입한 순서대로 검색하였을 때의 결과입니다. 역순으로 검색을 하였을때에는 아래와 같은 결과가 나옵니다.

각각 숫자와 문자, 심볼을 역순으로 검색하였을 때 출력된 시간입니다.

삽입 시간의 경우 변경된 것이 없지만 검색의 경우 문자와 심볼에서 Object가 Map에 비해 더 앞서는 것을 확인 할 수 있습니다.

결론적으로 실제로 빈번한 추가 및 제거에서는 Map이 확실히 앞서는 모습을 보여주었으나 검색은 경우에 따라 달라지는 것을 확인하였습니다. 다만 평균적으로 Map이 앞서는 것 같아 데이터를 다룰 때에는 Map을 사용하는 것이 더 좋아보입니다.

TCP ( Transmission Control Protocol )

imygnam — Fri, 1 Dec 2023 00:03:34 +0900

TCP ( Transmission Control Protocol )

Transmission : 전송

Control : 제어

Protocol : 프로토콜 ( 통신 규약 )

OSI 7 Layer에서 Transport Layer ( 4계층 )을 사용하는 프로토콜로 3계층에서 사용하는 IP와 같이 묶어서 TCP/IP라고 많이 부릅니다.

TCP란

TCP는 세그먼트 단위로 데이터 통신을 하기 위한 프로토콜이며 다음과 같은 특징을 가지고 있습니다.

1. 연결 지향적

TCP는 통신을 시작하기 전에 3-way handshake 방식으로 연결을 설정하고, 통신을 종료할때 4-way handshake 방식으로 연결을 종료합니다.

2. 신뢰성 있는 통신

TCP는 데이터 세그먼트의 순서, 손실을 관리하여 데이터가 정확하게 수신되도록 통신합니다. 이것이 가능하도록 TCP는 각 세그먼트에 순서 번호를 할당하고 수신자는 받은 세그먼트에 대해 확인 응답(ACK)를 보냅니다.

3. 전이중, 점대점 통신

TCP는 전이중 통신 ( 하나의 연결에 송수신이 동시에 가능 ) 이 가능하며, 점대점 방식 ( 하나의 연결은 정확히 2개의 종단점을 가짐 ) 으로 통신합니다.

4. 흐름 제어 ( Flow Control ) 과 혼잡 제어 ( Congestion Control )

흐름 제어와 혼합 제어를 통해 효율적인 데이터 전송을 합니다.

위 방식들에 대해 좀 더 자세히 알아보면 다음과 같습니다.

3-way handshake

SYN : Syncronize 의 약자로 "동기화"로 생각하면 됩니다.

ACK : Acknowledgment 의 약자로 "승인"으로 생각하면 됩니다.

명칭부터 3-way handshake이니 총 3번 통신이 발생합니다.

1. Client 측에서 Server 측에 SYN 패킷을 보내는데 이때 랜덤으로 생성한 Sequence Number를 담아 보냅니다.

2. Server 측은 수신한 Sequence Number에 1을 더하고 ACK 패킷을 Client에 보내는데 이때 SYN 또한 활성화 하여 보냅니다. 즉 ACK + SYN 패킷을 수신한 Sequence Number에 1을 더해 함께 보냅니다.

3. Client는 수신한 패킷의 Sequence Number가 자신이 보낸 것에 1 더해진 값이 맞는지 확인하고 정상이라면 Server에게 다시 ACK 패킷을 보냅니다. 서버가 이를 수신하면 연결이 완료된 상태입니다.

4-way handshake

FIN : Finish의 약자로 "끝"으로 생각하면 됩니다.

3-way handshake와 마찬가지로 명칭이 4-way handshake이니 총 4번 통신이 발생합니다.

1. Client 측에서 통신을 종료하겠다는 의미인 FIN 패킷을 Server 측에 보냅니다.

2. Server 측은 FIN 패킷을 수신하면 우선 알겠다는 의미로 ACK 패킷을 보냅니다.

3. 그 후 Server 측에서 FIN 패킷을 보내는데 만약 보낼 데이터가 남아 있다면 해당 데이터를 전부 보낸 다음 FIN 패킷을 보냅니다.

4. Client 측은 FIN 패킷을 받으면 확인했다는 의미로 ACK 패킷을 다시 Server 에 보냅니다. 이제 연결이 종료됩니다.

연결 후 통신 방식

연결이 성립된 후에는 이제 데이터를 주고 받아야합니다. 예를들어 Server 측에서 Client에게 데이터를 보낸다고 가정한다면 다음과 같은 과정을 거칩니다.

1. Application (Server) 이 데이터를 보내려고합니다. 해당 데이터를 보내기 위해 Socket Api 를 이용하여 Transport 계층으로 데이터를 내려보냅니다.

2. Transport 계층 ( TCP ) 는 해당 데이터를 받아 쪼개서 Segment 단위로 만들고 번호를 붙입니다. 그후 각 Segment를 Network 계층으로 내려보냅니다.

3. Network 계층은 받은 Segment 데이터를 Packet으로 변환하고 DataLink 계층으로 내려보내며 이때 Frame으로 변환합니다.

4. 해당 Frame은 Client까지 가게되고 Client는 해당 패킷을 받아 Transport 계층 ( TCP ) 까지 오게 됩니다. 올바른 Segment라면 Buffer에 담게 되고 잘 받았다고 Server에게 ACK를 해당 Segment 번호와 함께 보냅니다.

5. Server는 ACK를 받으면 다음 Segment를 전송합니다.

흐름 제어 ( Flow Control )

Sliding Window - 수신자가 처리할 수 있는 데이터의 양을 조절하여 Buffer Overflow를 방지하는 방식입니다.

위 과정에서 4,5를 진행함에 있어 1개씩 전송하면 매우 비효율적일 것입니다. 특히 TCP가 느린 이유중 가장 큰 원인은 해당 Segment를 보내고 ACK를 받기까지 Wait하고 있기 때문입니다. 하여 TCP는 4번과정에서 여러 Segment를 한번에 보내는데 이를 가능하게 하려면 Client 측의 Buffer 크기를 알아야합니다.

Client의 Buffer 보다 크게 보낸다면 Client는 해당 데이터를 전부 수신하지 못할 테고 이로인해 낭비가 크기 때문입니다. 따라서 Client는 Server 측에 남은 Buffer 크기 즉 Window Size를 보내줍니다. 그 크기를 확인하고 서버는 해당 크기에 알맞게 데이터를 보내게 됩니다.

초기 Window Size는 3-way handshake를 하는 중에 바로 보내줍니다. 즉 처음 SYN 과정에서 보내줍니다. 그 다음부터는 4번과정인 Server에 ACK를 보낼때 함께 보냅니다.

이렇게 Window Size가 확정된 후에는 각 Segment 를 보내고 ACK가 도착한다면 다음 패킷을 보내면 됩니다. 이것이 Window 가 점차 움직이는 것 처럼 보이기에 Sliding Window 라고 부릅니다.

혼잡 제어 ( Congestion Control )

Client가 수신할 수 있는 양과는 별개로 네트워크가 데이터를 감당하지 못할 수 있습니다. 특정 라우터에 데이터가 몰릴 경우, 해당 데이터를 모두 처리 할 수 없고 이로 인해 재전송이 발생하는 등 혼잡도가 증가하게 됩니다.

이러한 경우를 해결하기위해 송신하는 쪽에서 데이터의 전송속도를 조절하게 되는데 이 과정을 혼잡 제어라고 합니다. 혼잡 제어를 하는 방식은 여러가지가 있는데 다음과 같습니다.

AIMD ( Additive Increase / Multiplicative Decrease )

해석하면 "합 증가 / 곱 감소"로 말 그대로 선형적으로 증가하다 절반으로 감소하는 형태입니다. 초기에 Client에게 보내는 패킷 수를 1개씩 늘려가다가 전송이 실패하거나 일정시간 응답이 없다면 보내는 패킷 수를 절반으로 감소하는 방식입니다.

이 방식의 문제점은 초기부터 높은 전송 속도를 가질 수 없고, 네트워크가 혼잡해지고 나서야 대역폭이 줄기 때문에 혼잡해지는 상황을 미리 감지하지는 못한다는 것입니다.

Slow Start ( 느린 시작 )

느린 시작 방식은 AIMD 처럼 패킷을 초기에 1개씩 보내지만 성공적으로 ACK 가 수신된다면 수신된 만큼 Window Size 를 증가시키는 방법입니다. 즉 처음에 1개를 보내고 ACK개 1개 수신된다면 그다음은 2개를 보내고 2개의 ACK가 수신된다면 다음 4개를 보내는 방식으로 AIMD의 방식과 다르게 지수 함수 형태로 전송 속도가 증가하게 됩니다. 다만 전송 실패 시 ( Timeout ) AIMD 처럼 절반으로 떨어뜨리는 것이 아닌 창의 크기를 1로 떨어뜨립니다.

Fast Recovery ( 빠른 회복 )

네트워크에서 패킷 손실이 감지되면 윈도우 크기를 1로 줄이는 것이 아닌 절반으로 줄이는 것입니다.

보통 중복된 ACK 등 일부 패킷 손실 시에 Fast Recovery 를 진행하며 Timeout ( 타임아웃 )이 발생하면 Window Size를 1로 변경합니다.

ACK 가 중복이 일어났다는 것은 도착해야할 패킷보다 이후의 패킷이 먼저 도착했다는 의미입니다. 예를들어 1,2,3,4 를 전송했는데 도중 3이 사라졌다면 Client는 ACK 2,3을 전송하고 4가 왔을때에도 ACK 3을 전송하게 됩니다. 타임아웃은 설정된 시간내에 어떠한 ACK도 오지 않았을 때 발생합니다.

Congestion Avoidance ( 혼잡 회피 )

네트워크의 혼잡을 감지하면 전송률 증가를 늦추고, 순차적으로 증가시킵니다 ( AIMD 방식 ). 즉 Slow Start 이후에 특정 크기까지 전송 속도가 커진다면 이후로는 지수적으로 증가하는 것이 아닌 선형적으로 증가하는 형태로 변경합니다. 이 특정 크기는 ssthresh ( Slow Start Threshold ) 로 Slow Start와 Congestion Avoidance의 임계값이 됩니다.

Fast Retransmit ( 빠른 재전송 )

ACK의 중복이 발생했다는 것은 해당 패킷이 손실되었다는 것을 의미합니다. Fast Retransmit은 중복이 3번 반복 ( default ) 되면 해당 패킷의 ACK를 Timeout 될때까지 기다리는 것이 아니라 바로 재전송을 합니다. 물론 중복이 발생했기에 Fast Recovery 또한 진행됩니다.

즉 전체 혼잡 제어 기능을 살펴보면 다음과 같습니다.

1. Slow Start

2. ssthresh 만큼 Window Size가 커진다면 그 이후로는 Congestion Avoidance.

3. 통신 도중 패킷 손실 등 ACK 중복 발생시 Fast Recovery 만약 3회 이상이라면 Fast Retransmit 진행.

4. 통신 도중 TimeOut 발생시 Window Size 1로 변경

담쟁이

[AWS] non www 을 www 으로 redirect 하기 ( Netlify )

AWS Route53으로 netlify 에 redirect 하기.

non www 을 www으로 redirect 하기.

lambda 생성

트리거 추가 및 경로 추가

사용자 지정 도메인 이름 생성 및 API 매핑

Route53 레코드 생성

[Java] GC 종류별 메모리 상황에 따른 테스트

목차

15MB [ -Xms15m -Xmx15m ]

SerialGC

ParallelGC

G1GC

ZGC

50MB [ -Xms50m -Xmx50m ]

SerialGC

ParallelGC

G1GC

ZGC

100MB [ -Xms100m -Xmx100m ]

SerialGC

ParallelGC

G1GC

ZGC

결론

[Java] 버전별 GC 목록 ( OpenJDK )

GC 확인 방법

1. 적용중인 Flag를 확인하는 방법

2. 전체 Flag를 확인하는 방법

Java8 에서의 GC

Java11에서의 GC

Java17에서의 GC

Java21에서의 GC

[JAVA] JVM 동작 방식

JVM이란

Class Loader

Execution Engine

Runtime Data Areas

[LOL-DUO] Lamdba 로 데이터를 크롤링해 RDS 에 데이터 저장하기.

1. 목표

2. 아키텍처 설계 과정

2.1 Lambda로 진행한 이유

2.2 Lambda가 2개로 나뉘어진 이유

2.3 JS로 진행한 이유

3. 개발 과정

3.1 VPC 내부에 Lambda 생성하기.

3.2 Lambda 함수 개발 ( JS )

쿠키 ( Cookie ), 세션 ( Session )

1. 쿠키 ( Cookie )

2. 세션 ( Session )

[Java] Java version 별 차이 ( 7, 8, 9, 11 )

java 7

java 8

1. 인터페이스 ( interface ) 에서 Default Method

2. 람다 표현식, 함수형 인터페이스

3. Optional 구조체

4. java.time 패키지

5. Stream API

6. GC 성능 개선

java 9

1. Java Platform Module System ( jigsaw project )

2. G1 GC

3. HTTP/2 지원

java 11

1. HTTP/2 강화

2. 람다 표현식에서 로컬 변수 타입 추론 ( var )

[TypeScript] Type Compatibility ( 타입 호환성 )

타입 호환성이란?

함수의 비교

열거형의 비교

클래스의 비교

제네릭의 비교

Freshness ( 신선도 ) 란

[JavaScript] Object VS Map ( 성능 비교 )

Object

Map

TCP ( Transmission Control Protocol )

TCP ( Transmission Control Protocol )

TCP란