week 3 jisoo - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 저장하는 영역이다.

JVM이 운영체제 위에서 실행되면서 할당받는 메모리 영역이다. Class Loader에서 준비한 데이터들을 보관하는 저장소이다.

이 영역은 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

이중에 Heap 영역과 Stack 영역을 비교해보려 한다.

• JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.
• New 연산자로 생성된 객체 또는 객체(인스턴스)와 배열을 저장한다.
• 힙 영역에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다.
• 참조하는 변수나 필드가 없다면 의미 없는 객체가 되어 GC의 대상이 된다.
• 힙 영역의 사용기간 및 스레드 공유 범위 객체가 더 이상 사용되지 않거나 명시적으로 null 선언 시 GC(Garbage Collection) 대상 구성 방식이나 GC 방법은 JVM 벤더마다 다를 수 있다. 모든 스레드에서 공유한다.

지역 변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값등이 생성되는 영역이다.

int a = 10; 이라는 소스를 작성했다면 정수값이 할당될 수 있는 메모리공간을 a라고 잡아두고 그 메모리 영역에 값이 10이 들어간다. 즉, 스택에 메모리에 이름이 a라고 붙여주고 값이 10인 메모리 공간을 만든다.

클래스 Person p = new Person(); 이라는 소스를 작성했다면 Person p는 스택 영역에 생성되고 new로 생성된 Person 클래스의 인스턴스는 힙 영역에 생성된다.

그리고 스택영역에 생성된 p의 값으로 힙 영역의 주소값을 가지고 있다. 즉, 스택 영역에 생성된 p가 힙 영역에 생성된 객체를 가리키고(참조하고) 있는 것이다.

메소드를 호출할 때마다 개별적으로 스택이 생성된다.

• 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다.
• 메소드를 호출할 때마다 프레임(Frame)을 추가(push)하고 메소드가 종료되면 해당 프레임을 제거(pop)하는 동작을 수행한다.
• 선입후출(FILO, First In Last Out) 구조로 push와 pop 기능 사용
• 메소드 호출 시 생성되는 스레드 수행정보를 기록하는 Frame을 저장
• 메소드 정보, 지역변수, 매개변수, 연산 중 발생하는 임시 데이터 저장
• 기본(원시)타입 변수는 스택 영역에 직접 값을 가진다.
• 참조타임 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다.

함수형 프로그래밍은 함수의 입력만을 의존하여 출력을 만드는 구조로 외부의 상태를 변경하는 것을 지양하는 패러다임으로 부작용 발생을 최소화하는 방법론.

• 순수한 함수

  • 함수의 실행이 외부의 상태를 변경하지 않음.
  • 멀티쓰레드에서도 안전하고, 병렬처리 및 계산 가능
  • 오직 입력에 의해서만 출력이 정해짐. 환경이나 상태에 영향을 받아선 안됨!

• 익명 함수

  • 이름이 없는 함수
  • 대부분의 프로그래밍 언어에서 람다식으로 표현

• 고계 함수

  • 함수를 다루는 상위의 함수
  • 함수도 하나의 값으로 취급
  • 함수의 인자로 함수를 전달 가능
  • ⇒ 일급 객체 (일급 함수)

  JAVA에는 함수의 개념이 없었다.

  자바의 메소드는 일급 함수가 아니므로 다른 메소드의 인자로 전달할 수도 없었다.

  또한 자바는 객체 지향 프로그래밍의 특성으로 메소드는 객체의 행위를 정의하고 객체의 상태를 변경한다.

  때문에 JAVA8에서 단 하나의 메소드만이 선언된 인터페이스인 함수형 인터페이스를 도입한다.

  함수형 인터페이스의 경우 람다식으로 표현이 가능할 수 있게 제공되었다.

  • 순수 함수 만족 : 람다식 표현을 통해 입력을 통해서만 출력이 결정됨
  • 익명 함수 만족 : 람다식을 이용하여 익명 함수 정의 가능
  • 고계 함수 만족 : 함수형 인터페이스의 메소드에서 또다른 함수형 인터페이스를 인자로 받을수 있음.

  ⇒ 즉 함수형 인터페이스와 람다식의 도입으로 JAVA는 함수형 프로그래밍의 조건을 만족 하게 됨.

• Java8에서는 함수를 일급객체처럼 다룰 수 있게 **함수형 인터페이스**를 제공한다. = 람다식을 다루기 위한 인터페이스

• 람다식과 인터페이스의 메서드가 1:1로 연결되어야 하기 때문에 단 하나의 추상 메서드만 가지는 인터페이스를 의미한다.

   (static함수는 여러 개 가질 수 있다.)
  

• 일급객체란 아래 조건을 만족해야 한다.

• **변수에 값을 할당 할 수 있어야 한다.

• 함수의 파라미터로 넘겨줄 수 있어야 한다.

• 함수의 반환값이 될 수 있어야 한다.**

• 함수형 인터페이스를 이용함으로서 객체를 선언하고 오버라이딩하는... 이런 번거로운 작업들을 없애고 단순히 람다식 함수를 통해 코드를 간결하게 작성 할 수 있다.

java의 큰변화는 jdk1.5부터 추가된 제네릭스의 등장이고, 또 한번은 jdk 1.8부터 추가된 람다식의 등장이다.

람다식의 도입으로 인해 이제 자바는 객체지향언어인 동시에 함수형 언어가 되었다.

람다식이란 간단히 말해서 메서드를 하나의 식으로 표현한 것이다. 메서드를 람다식으로 표현하면 메서드의 이름과 반환값이 없어지므로, 람다식을 익명함수라고도 한다.

람다식 문법은 컴파일러가 익명 클래스로 변환한다. 즉, 함수형 인터페이스를 컴파일러가 구현하도록 위임하는 형태라 볼 수 있다

int[] arr = new int[5];
Arrays.setAll(arr, (i) -> (int)(Math.random()*5) +1);

// 위 람다식은 아래 메서드와 같다.
int method() {
		return (int)(Math.random()*5) + 1;
}

기존에는 모든 메서드는 클래스에 포함되어야 하므로, 클래스도 새로 만들어야 하고, 객체도 생성해야만 비로소 메소드를 호출할 수 있었는데, 람다식은 이 모든 과정없이 오직 람다식 자체만으로 메서드의 역할을 대신할 수 있다.

게다가 람다식은 메서드의 매개변수로 전달되어지는 것이 가능하고, 메서드의 결과로 반환될 수 있다. 람다식으로 인해 메서드를 변수처럼 다루는 것이 가능해진 것이다.

• 메서드와 함수의 차이 : 객체지향 개념에서는 함수 대신 객체의 행위나 동작을 의미하는 메서들는 용어를 사용했다. (메서드는 객체에 반드시 속해야함). 그러나 이제 다시 람다식을 통해 메서드가 하나의 독립적인 기능을 하기때문에 함수라는 용어를 사용할 수 있다.

메소드 레퍼런스(Method Reference)는 Lambda 표현식을 더 간단하게 표현하는 방법이다.

메서드 레퍼런스는 이름에서 알 수 있듯이 메서드의 레퍼런스를 전달한다는 의미이며, 람다표현식에서 메서드 호출 1회로 코드가 끝나는 경우 메서드 레퍼런스를 이용해 이미 줄인 코드를 더 줄일수도있다.

메서드의 레퍼런스라고하지만 엄밀히 말해 자바에서의 메서드는 일급 객체가 아니기때문에 객체의 레퍼런스를 전달하는 방식으로 작동한다.

Method Reference를 만드는 유형에는 다음 3가지가 있다.

1. 정적 메서드 참조: Integer의 parseInt를 Integer::parseInt로 사용 가능
2. 다양한 형식의 인스턴스 메서드 참조: String의 length 메서드를 String::length로 사용 가능
3. 기존 객체의 인스턴스 메서드 참조: Transaction 객체를 할당받은 transaction 지역 변수가 있고, Transaction 객체에는 getValue 메서드가 있다면, transaction::getValue로 사용 가능

1. 정적 메서드 참조 (정적 클래스::메서드명)

: 파라미터로 전달받은 변수의 메서드를 사용하지 않고, 정적 메서드의 인자로 사용됨. (String x) -> Integer.parseInt(x) 의 경우 파라미터 x를 parseInt의 인자로 사용되는 것을 볼 수 있음.

Function<String, Integer> f = Integer::parseInt;
Integer result = f.apply("123");

출처: https://multifrontgarden.tistory.com/126 [우리집앞마당]

Integer 클래스의 정적 메서드인 parseInt()를 메서드 레퍼런스로 전달하는 예시를 생각해보자. 해당 구현체 소스에서 사용할 수 있는 지역변수는 String 타입의 str밖에 없다. 그리고 리턴타입은 제네릭을 이용해 Integer를 건네줘야하는걸 추론할 수 있다. 때문에 메서드만 전달해주면 컴파일러가 알아서 호출해주는것이다.

2. 인스턴스 메서드 참조

: 1번과 비슷한데 차이점이라면 정적 메서드의 인자가 아닌 기존에 이미 생성된 인스턴스의 인자로 사용 된다.

인자의 타입이 명확할때 해당 타입 클래스::메서드명 형식으로 작성한다.

Function<String, Boolean> f = String::isEmpty;
Boolean result = f.apply("123");

3. 생성자 메서드 참조

: Constructor 메소드 레퍼런스는 Constructor를 생성해주는 코드이다.

public static class Company {
    String name;
    public Company(String name) {
        this.name = name;
    }

    public void printName() {
        System.out.println(name);
    }
}

public static void main(String args[]) {
		List<String> companies = Arrays.asList("google", "apple", "google", "apple", "samsung");
		companies.stream()
			      .map(Company::new)
		        .forEach(Company::printName);
}

위 예제 코드에서 Company::new 의 의미는 name -> new Company(name)와 같다.

예외 클래스의 구조

• 모든 예외클래스는 Throwable 클래스를 상속받고 있으며, Throwable은 최상위 클래스 Object의 자식 클래스이다.
  

Throwable을 상속받는 클래스는 Error와 Exception이 있다.

• Error는 시스템 레벨의 심각한 수준의 에러이기 때문에 시스템에 변화를 주어 문제를 처리해야 하는 경우가 일반적이다.

• 반면 Exception은 개발자가 로직을 추가하여 처리할 수 있다.
  

• Exception은 수많은 자식클래스를 가지고 있다. 그 중 RuntimeException을 주목해야 한다.

• RuntimeException은 CheckedException과 UncheckedException을 구분하는 기준이다.

• Exception의 자식 클래스 중 RuntimeException을 제외한 모든 클래스는 CheckedException이며,

• RuntimeException과 그의 자식 클래스들을 Unchecked Exception이라 부른다.
  

CheckedException과 UncheckedException에 대해 더 자세히 살펴보자.

• Checked Exception과 Unchecked Exception의 가장 명확한 구분 기준은 ‘꼭 처리를 해야 하느냐’이다.
  

• Checked Exception이 발생할 가능성이 있는 메소드라면 반드시 로직을 try/catch로 감싸거나 throw로 던져서 처리해야 한다.
  

• 반면에 Unchecked Exception은 명시적인 예외처리를 하지 않아도 된다. 이 예외는 피할 수 있지만 개발자가 부주의해서 발생하는 경우가 대부분이고, 미리 예측하지 못했던 상황에서 발생하는 예외가 아니기 때문에 굳이 로직으로 처리를 할 필요가 없도록 만들어져 있다.
  

• 또한 예외를 확인할 수 있는 시점에서도 구분할 수 있다. 일반적으로 컴파일 단계에서 명확하게 Exception 체크가 가능한 것을 Checked Exception이라 하며, 실행과정 중 어떠한 특정 논리에 의해 발견되는 Exception을 Unchecked Exception이라 한다.
  

• 따라서 컴파일 단계에서 확인할 수 없는 예외라 하여 Unchecked Exception이며, 실행과정 중 발견된다 하여서 Runtime Exception이라 하는 것이다.
  

• 또한 Checked Exception / Unchecked Exception 예외발생시 트랜잭션의 roll-back 여부도 다르다.
  

• 기본적으로 Checked Exception은 예외가 발생하면 트랜잭션을 roll-back하지 않고 예외를 던져준다.

• 하지만 Unchecked Exception은 예외 발생 시 트랜잭션을 roll-back한다는 점에서 차이가 있다.
  

• 트랜잭션의 전파방식 즉, 어떻게 묶어놓느냐에 따라서 Checked Exception이냐 Unchecked Exception이냐의 영향도가 크다.
  roll-back이 되는 범위가 달라지기 때문에 개발자가 이를 인지하지 못하면, 실행결과가 맞지 않거나 예상치 못한 예외가 발생할 수 있다.
  

그러므로 이를 인지하고 트랜잭션을 적용시킬 때 전파방식(propagation behavior)과 롤백규칙 등을 적절히 사용하면 더욱 효율적인 애플리케이션을 구현할 수 있을 것이다.

Spring의 IoC 컨테이너에서 관리되는 객체임을 표시하기 위해 사용하는 가장 기본적인 annotation이다. 즉, scan-auto-detection과 dependency injection을 사용하기 위해서 사용되는 가장 기본 어노테이션이다.

이외에 나머지 @Service, @Controller, @Repository 어노테이션은 애플리케이션에서 레이어를 분리하는데 사용된다.

Web MVC 코드에 사용되는 어노테이션이다. @RequestMapping 어노테이션을 해당 어노테이션 밑에서만 사용할 수 있다.

다 알고 있듯이 data repository를 나타내는 어노테이션이다. @Repository는 플랫폼 특정 exception을 잡아 Spring의 unchecked exception으로 뱉어내준다. ( PersistenceExceptionTranslationPostProcessor )

비즈니스 로직이나 respository layer 호출하는 함수에 사용된다. 다른 어노테이션과 다르게 @Component에 추가된 기능은 없다. 하지만 나중에 Spring 측에서 추가적인 exception handling을 해줄 수도 있으니 비즈니스 로직에는 해당 어노테이션을 사용하자.

1. 클라이언트의 요청이 DispatcherServlet에 전달
2. DispatcherServlet은 HandlerMapping을 사용, 클라이언트의 요청을 처리할 컨트롤러 객체를 찾음
3. DispatcherServlet은 컨트롤 객체의 handleRequest() 메소드를 호출하여, 클라이언트의 요청을 처리한다.
4. Controller.handleRequest() 메소드는 처리 결과 정보를 담은 ModelAndView 객체를 리턴한다.
5. DispatcherServlet은 ViewResolver로 부터 처리결과를 보여줄 View를 구한다.
6. View는 클라이언트에 전송할 응답을 생성한다.

1. DispatcherServlet : 클라이언트의 요청을 전달받아 요청에 맞는 컨트롤러가 리턴한 결과값을 View에 전달하여 알맞은 응답을 생성한다.
2. HandlerMapping : 클라이언트의 요청 URL을 어떤 컨트롤러가 처리할지 결정
3. Controller : 클라이언트의 요청을 처리한 뒤, 결과를 DispatcherServlet에게 리턴
4. ModelAndView : 컨트롤러가 처리한 결과 정보 및 뷰 선택에 필요한 정보들 담음
5. ViewResolver : 컨트롤러의 처리 결과를 생성 할 뷰를 결정
6. View : 컨트롤러의 처리 결과 화면을 생성

출처: https://csw7432.tistory.com/entry/Spring-MVC-주요-구성-요소-및-처리-흐름 [최느님 프알못]

Annotation기반의 스프링 MVC를 사용할 때에 설정을 편하게 해주는 기능을 한다. 어플리케이션 컨텍스트 설정 파일에 @EnableWebMvc를 붙여주면 이 어플리케이션 컨텍스트 설정파일을 사용하고 있는 DispatcherServlet이 갖게 되는 여러가지 전략들에 변화 혹은 추가가 생기고 커스터마이징 하기가 더 용이해진다.
@EnableWebMvc를 통해 추가된 bean들의 설정을 커스터마이징하게 하는 원리는 '위임'구조이다. @EnableWebMvc에 들어가보면 여러 내장 함수들이 WebMvcConfigurerComposite의 설정을 잡아주도록 생성되어있다. 따라서 이를 우리가 원하는 대로 커스터마이징 하기 위해서는 WebMvcConfigurer를 상속하도록 하여 WebMvcConfigurer이 가진 자원을 통해 원하는 커스터마이징을 실현하는 것이다.

@Configuration
@ComponentScan
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void configureViewResolvers(ViewResolverRegistry registry) {
        registry.jsp("/WEB-INF/", ".jsp");
    }
}

JVM Heap Area 의 구성 new 연산자로 생성된 객체와 배열을 저장하는 공간입니다. GC 로 사용하지 않는 객체들은 메모리로 반환됩니다. Heap Area 종류 Permanent Generation: 생성된 객체들의 정보의 주소값이 저장된 공간 New Area Eden: 객체들이 최초로 새성되는 공간 Survivor: Eden에서 참조되는 객체들이 저장되는 공간 실제 통계로도 생성된 98% 객체가 곧바로 쓰레기 객체가 된다고 한다. Old Area New Area 에서 일정시간이상 참조되고 있는 객체들이 저장되는 공간

• Cache?
  • 한번 읽은(처리한) 데이타를 임시로 저장하고 필요에 따라 전송,갱신,삭제하는 기술로 보통은 데이타의 보관장소로 서버의 메모리를 사용하는 경우가 많다
  • 그렇기 때문에 디스크에서 정보를 얻어오는 것보다 훨씬 빠른 I/O성능을 얻을 수 있으나 서버가 다운되거나 재부팅되는 경우 사라지는 성격의 휘발성을 가지고 있어
  • 영속적으로 보관할 수 없는, 말 그대로 임시적으로 보관하고 빠르게 그 정보에 접근하기 위한 용도로 사용해야 한다.(물론 정보의 성격에 따라 별도의 디스크백업 및 TTL등의 설정으로 영구보관이나 오랜기간 유지가 가능하다. 단 이런 설정들이 꼭 필요하다면 Cache를 적용하는게 맞는지 한 번도 타당성을 검토해 보는게 좋겠다)
• Cache를 쓰는 목적은 단순하다.
  • 서버간 불필요한 트래픽을 줄일 수 있고,
  • 그로 인해 웹어플리케이션 서버의 부하 감소시키고,
  • 어플리케이션의 빠른 처리성능(조회)을 확보해서 궁극적으로 어플리케이션를 사용하는 고객에게 쾌적한 서비스경험을 제공하는 것이다.

1. 단순한, 또는 단순한 구조의 정보를 -> 정보의 단순성
2. 반복적으로 동일하게 제공해야 하거나 -> 빈번한 동일요청의 반복
3. 정보의 변경주기가 빈번하지 않고, 단위처리 시간이 오래걸리는 정보이고 -> 높은 단위처리비용
4. 정보의 최신화가 반드시 실시간으로 이뤄지지 않아도 서비스 품질에 영향을 거의 주지 않는 정보

• 포탈의 검색어
• 쇼핑몰의 핫딜상품, 베스트셀러, 추천 상품등
• 상품의 카테고리와 카테고리별 등록 상품 수
• 방문자 수, 조회 수, 추천 수
• 1회성 인증정보 (SMS 본인인증정보, IP 정보등)
• 공지사항, Q&A
• MSA 구조에서는 다른 서비스 요청에 대한 응답 데이터 저장은 거의 필수적!
• 우리가 웹사이트에서 보는 대부분의 이미지는 다 캐싱된 이미지이다.(CDN의 가장 중요한 기능)

암호화 통신은 일반적으로 TLS/SSL 프로토콜을 사용하여 이루어지는데 TLS/SSL 암호화 과정에서 필요한 정보(사용할 암호화 알고리즘, 키) 의 교환을 위한 TLS Handshake 과정이 존재합니다. 해당 과정을 통하여 세션을 생성할 수 있고 이 후 두 노드의 통신은 세션 상에서 수행됩니다. SSL/TLS handshake를 사용하면 SSL 또는 TLS 클라이언트 및 서버가 통신하는 보안 키를 설정할 수 있습니다.

SSL(Secure Sockets Layer)은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트 인증을 하는데 사용됩니다. 주로 전송계층과 응용계층 사이에서 보안조치를 하는 데 사용합니다. HTTPS:// 는 SSL을 사용하는 경우를 의미하는 것이죠.

TLS(Transport Layer Security) 로 최근에 부르는데 SSL은 과거 명칭이라서 같은 말입니다.

모든 SSL/TLS 연결은 "Handshake" 과정을 거쳐야 합니다. handshake 과정은 통신을 암호화하는 데 사용할 암호화 알고리즘과 키를 결정하고 서버를 확인하며 실제 데이터 전송을 시작하기 전에 보안 연결이 이루어 졌는지 확인합니다. 이 연결을 확인하기 위한 과정때문에 handshake라고도 하죠.

1. 사용할 프로토콜 버전에 동의.

2. 암호화 알고리즘 선택.

3. 디지털 인증서 교환하고 유효성 검사하여 서로 인증.

4. 비대칭 암호화 기술을 사용하여 공유 비밀키를 생성. 그런 다음 SSL 또는 TLS는 공유키를 사용하여 메세지를 대칭 암호화 방식으로 암호화.

대칭키가 가지는 해킹의 위험을 막고자 나온 것이 바로 공개키(Public Key)인데요. 암호화와 복호화에 사용하는 키를 분리하는 방식입니다.

'handshake' 그 자체는 비대칭 암호화를 사용합니다. 공개키와 개인키도 각각 별도로 사용됩니다. 비대칭 암호화 시스템은 높은 오버헤드를 가지고 있기 때문에 모든 보안 과정을 제공하는 데 사용할 수 없습니다. 그래서 공개키는 handshake 하는 동안 암호 해독을 위한 암호화 및 개인키로 사용되며 서버와 클라이언트가 각각 새로 생성한 공유키를 설정하고 교환하게 합니다.

세션 자체는 공유키를 사용하여 대칭 암호화를 수행하기 때문에 실제 연결에서 오버 헤드를 줄여줍니다.

1. SSL / TLS 클라이언트 컴퓨터가 자신의 버전, 암호 알고리즘 목록, 그리고 사용 가능한 압축 방식을 "client hello" 메시지에 담아 서버로 보냅니다.

2. SSL / TLS 서버는 클라이언트가 제공한 목록에서 서버가 선택한 암호 알고리즘, 선택한 압축 방식과 세션 ID 및 CA(Certificate Authority)가 사인한 서버의 공개 인증서를 "server hello" 메시지에 담아 응답합니다. 이 인증서는 대칭키가 생성되기 전까지 클라이언트가 나머지 handshake 과정을 암호화하는 데에 쓸 공개키를 담고 있습니다.

3. SSL / TLS 클라이언트는 서버의 디지털 인증서가 유효한지 신뢰할 수 있는 CA 목록을 통해 확인합니다.

4. 만약 CA를 통해 신뢰성이 확보되면 클라이언트는 의사 난수(pseudo-random) 바이트를 생성해 서버의 공개키로 암호화합니다. 이 난수 바이트는 대칭키를 정하는 데에 사용되며 이 대칭키는 나중에 메시지 데이터를 암호화하는 데 사용됩니다.

5. SSL / TLS 서버가 "클라이언트 인증서 요청"을 보낸 경우 클라이언트는 클라이언트의 디지털 인증서 또는 "디지털 인증서 없음 경고" 와 함께 클라이언트의 개인 키로 암호화 된 임의의 바이트 문자열을 보냅니다. 이 경고는 경고일 뿐이지만 일부 구현에서 클라이언트 인증이 필수일 경우 handshake 실패합니다.

6. 서버는 클라이언트의 인증서를 확인합니다. 난수 바이트를 자기 개인키로 복호화해 대칭 마스터키 생성에 활용합니다.

7. 클라이언트는 handshake의 클라이언트 부분이 완료되었음을 알리는 Finished 메시지를 서버에 보내면서 지금까지의 교환 내역을 해시한 값을 대칭키로 암호화하여 담습니다.

8. 서버는 스스로도 해시를 생성해 클라이언트에서 도착한 값과 일치하는지 봅니다. 일치하면 서버도 마찬가지로 대칭키를 통해 암호화한 Finished 메시지를 클라이언트에게 보냅니다.

9. 이후부터 SSL / TLS 세션 동안 서버와 클라이언트는 대칭키로 암호화된 어플리케이션(HTTP) 데이터를 주고 받을 수 있습니다.

출처:

https://wangin9.tistory.com/entry/브라우저에-URL-입력-후-일어나는-일들-5TLSSSL-Handshake

[잉구블로그]