7주차 개념 노트

# Hypertext Transfer Protocol (HTTP)란?

HTTP는 HTML같은 하이퍼미디어 문서를 전송하기 위한 OSI 7계층의 어플리케이션 레이어 프로토콜이다. 

HTTP는 클라이언트가 요청을 생성하기 위한 연결을 요청을 받을때 까지 대기하는 전통적인 클라이언트-서버 모델이며,

무상태 프로토콜이다. 이는 서버가 두 요청간에 어떠한 데이터도 유지하지 않음을 의미한다. 

따라서 무언가 연속적인 요청을 하려면 서버는 응답을 할 때 헤더에 쿠키 정보를 넣어 응답을 하고 클라이언트는 쿠키를 받으면 requestHeader의 쿠키 헤더에 쿠키 정보를 넣음으로서 상태가 유지되는 것 처럼 보이는 통신을 할 수 있게 된다. 

 

* 어플리케이션 레이어 : 사용자의 데이터와 직접 상호 작용하는 유일한 계층. 브라우저나 클라이언트와 같은 소프트웨어 어플리케이션은 통신을 개시하기 위해 어플리케이션 계층에 의지한다. 프로토콜은 HTTP, FTP, SMTP 등이 있다. 

# HTTP 특징 

클라이언트 서버 모델 : 

클라이언트 서버 모델은 클라이언트가 요청하면 서버가 요청을 수신하고 처리해서 클라이언트에게 응답을 전달하는 형식. 

통상적으로 클라이언트가 서버에 요청을 전달하는 것으로 통신이 시작된다. 

 

*서버 : 웹페이지, 사이트, 앱을 저장하는 컴퓨터, 클라이언트의 요청을 받아 처리하고 응답을 클라이언트에 보냄. 

* 클라이언트 : 서버와 이어지는 모든 단말. 보통 브라우저랑 게임과 같이 별도 클라이언트가 서버랑 호응한다. 

 

무상태 프로토콜 Stateless: 

 

HTTP 통신에서 서버는 클라이언트의 상태를 저장하지 않는다. 즉 클라이언트가 이전에 했던 요청이 무엇인지에 따라 반응이 달라지지 않는다. Stateless가 중요한 이유는 서버가 확장 가능해야 하기 때문. 서버가 많아질수록 서버 간 정보를 공유하기 위한 비용이 높아져서 Stateless를 이용해 정보 공유를 최소화한다. 

 

*클라이언트에서 이전에 자신이 요청한 정보를 저장해놓고 해당 메세지를 함께 보내서 각 서버가 메세지를 독립적으로 처리할 수 있게 되면서 성능 향상과 비용 절감이 이루어진다. (쿠키)

 

비연결성 :

연결성이라면 클라이언트가 서버에 요청을 보내고 응답을 받더라도 서버에 접속된 상태로 남게되어 서버의 자원이 소모된다. 따라서 요청을 보내고 응답을 받게 되면 바로 클라이언트와 서버의 연결을 끊어 서버 자원을 최소한만 사용하게 하는 것.

 

장점 :

• 일반적으로 수천 명이 서비스를 이용해도 동시 처리하는 요청은 수십개 이하로 매우 적다. 서버 자원을 효율적으로 사용할 수 있다.

단점 : 

• 매번 TCP/IP 연결을 새로 맺어야한다 => 3 way handshake 오버헤드 시간 추가
• HTTP 1.1 이후로는 지속 연결으로 문제를 해결했다 =>  웬만한 리소스를 다 다운 받기 전까지 연결을 유지하고 다운로드가 끝난 후 연결을 종료한다. HTTP 1.0 버전에서는 request header에 connection:keep-alive를 이용한다. 

# HTTPS (HyperText Transfer Protocol over Secure Socket Layer)

 HTTP의 보안이 강화된 버전이다. 소켓 통신에서 일반 텍스트를 이용하는 대신에 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화해서 데이터를 주고 받는 모든 통신 내용이 암호화된다. 기본 TCP/IP 포트는 443. 

서버와 클라이언트는 공개키 저장소에 자신의 공개키를 등록하고 상대방의 공개키를 획득해서 상대방의 공개키를 이용해 데이터를 암호화 시켜서 전송한다. 그리고 상대방은 개인키를 이용해서 공개키로 암호화된 암호문을 복호화해서 내용을 알 수 잇게 된다. 

 

* TLS는 SSL 3.0을 베이스로 표준화를 한 것. SSL은 더 이상 사용되지 않는다. 

 

장점 : 

• HTTPS 웹사이트는 무결성을 보호해주고, 웹 사이트와 사용자 브라우저 사이의 통신을 침입자가 건드리지 못 하게 한다.
• 보안 요소는 키워드 검색 시 상위 노출되는 기준 중 하나이다.

단점 : 

• 모든 사이트에서 텍스트를 암호화해서 주고 받으면 프로세서에 과부하가 걸려 속도가 느려질 수 있다. 중요한 사이트에만 HTTPS로 관리하고 그렇지 않는 사이트는 HTTP를 사용한다.

# Static web page , Dynamic web page 

정적 웹 페이지 :

서버에 미리 저장된 파일(HTML, CSS, JS, 이미지 등) 불러와 구성하는 페이지. 서버에 저장된 데이터가 변경되지 않는 한 사용자는 고정된 웹페이지를 보게 된다.

 

장점 : Request에 대한 데이터만 전송하고 추가적인 작업이 없음으로 빠르고 비용이 적게 든다 

단점 : 저장된 데이터만 보여줄 수 있어 서비스가 한정적이고, CRUD 모두 수동적이므로 관리가 힘들다. 

 

동적 웹 페이지 : 

서버에 있는 데이터들을 사용자 Request에 따라 가공 처리한 후 구성하는 페이지. 사용자의 Request에 따라 데이터를 가공한 후 사용자는 달라지는 웹 페이지를 보게 된다 

 

장점 : 사용자의 Request에 따라 동적으로 페이지를 생성, 제공하므로 서비스가 다양함. CRUD 등 작업의 관리가 쉽다 

단점 : 사용자에게 웹 페이지를 구성해주기 전 처리하는 비즈니스 로직이 있어 상대적으로 느리다. 비즈니스 로직을 처리하는 Web Application Server가 필요해 추가적인 비용이 든다 

# Web Server

웹서버는 정적 컨텐츠(HTML, CSS, JS, 이미지 등)을 사용자에게 제공하는 서버. 크게 소프트웨어와 하드웨어적 관점으로 구분할 수 있다. 소프트웨어적 관점으로는 클라이언트로 부터 HTTP 요청을 받은 후 HTML, CSS, JS 등 같은 정적 컨텐츠를 제공해주는 프로그램. 

하드웨어적 관점으로는 위 소프트웨어적 관점에서 본 프로그램을 탑재한 컴퓨터 시스템, 아파치, 엔진 등이 있다 

• 정적 컨텐츠 제공 -> WAS를 거치지 않는다
• 동적 컨텐츠 제공을 위한 요청 전달 -> 클라이언트 요청을 WAS에 보내고 WAS에서 처리한 결과를 클라이언트에게 전달 

# Web application server

웹 어플리케이션 서버는 흔히 웹 컨테이너, 서블릿 컨테이너로 불리며 DB 조회 및 다양한 로직 처리 요구 시 동적인 컨텐츠를 제공하기 위해 만들어진 애플리케이션 서버로 동적 컨텐츠를 제공하는 서버이다.

• 컨테이너란 JSP, Servelt을 실행시킬 수 있는 소프트웨어, DB서버와 함께 사용되며 보안, 스레드 처리, 분산 트랜젝션 등 분산 환경에 사용된다. 
• 프로그램 실행 환경 및  DB 접속 기능 제공
• 여러 트랜젝션 관리 기능 
• 업무를 처리하는 비즈니스 로직 수행 

WAS 동작과정

1. 웹 서버로 부터 요청이 들어오면 제일 먼저 컨테이너가 이를 알맞게 처리한다
2. 컨테이너는 배포 서술자(web.xml)을 참조하여 해당 서블릿에 대한 스레드를 생성하고 요청 
3. 컨테이너는 서블릿을 호출한다
4. 호출된 서블릿의 작업을 담당하게 된 미리 생성된 스레드는 요청에 따라 doPost() 또는 doGet()을 호출한다
5. 호출된 메서드는 생성된 동적 페이지를 Resposne 객체에 실어서 컨테이너에 전달 
6. 컨테이너는 전달받은 Response 객체를 HTTPResponse 형태로 전환해서 웹서버에 전달하고 생성되었던 스레드를 종료하고 httpServeletRequest 및 httpServletResponse객체를 소멸시킨다.

# Cookie와 Session 

HTTP 포로토콜은 "무연결성, 무상태"한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 한다. 이 특성을 보완하기 위해 쿠키와 세션을 사용한다.

 

Cookie : HTTP Cookie는 클라이언트(브라우저)가 저장하고 있는 Key-value 값을 의미한다. (그림 왼쪽은 쿠키의 발급 과정) 

• 클라이언트는 서버에게 요청을 한다
• 서버는 클라이언트에게 응답을 할 때 Set-Cookie Header에 Cookie 정보를 전송한다. Cookie의 만기 기간, 유효 범위, 정보도 같이 보낸다. 
• 클라이언트는 쿠키를 저장하고 있으면 저장한 쿠키 정보 바탕으로 적절한 쿠키를 Cookie Header에 포함시켜 전송한다. 
• 쿠키는 두 요청이 동일한 브라우저에서 왔는지 아닌지 판단할 때 사용한다 Stateless HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문. 
• 세션관리, 개인화, 트래킹을 위해 사용하지만 요즘은 localStorage나, sessionStorage를 사용하면 된다. 

Session : 쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다. 

• 서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하고 우베 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다. 또한 접속 시간에 제한을 두어 일정 시간 응답이 없으면 유지되지 않게 설정이 가능하다 
• 서버에 정보를 두기 때문에 쿠키보다 보안에 좋지만 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다
• 클라이언트가 요청을 보내면, 해당 서버 엔진이 클라이언트에게 유일한 ID를 부여하는데 이것이 세션 ID이다. 
• 클라이언트가 서버에 접속 시 세션 ID를 발급받고, 클라이언트는 쿠키를 사용해서 이를 저장하고 있는다. 그리고 클라이언트는 서버에 요청할 때 쿠키의 세션 ID를 서버에 전달해서 요청하고 서버는 세션 ID를 전달 받아서 별 작업 없이 세션ID로 있는 세션에 있는 클라이언트 정보를 가져와서 사용.

차이 : 

• 정보 저장 위치가 다르다. 쿠키는 클라이언트, 세션은 서버
• 세션은 서버에 저장되기 때문에 쿠키에 비해 보안 면에서 우수하다. 다만 쿠키는 서버의 처리가 필요하지 않기 때문에 처리 속도가 빠르다. 
• 쿠키는 만료 시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속 정보가 남아 있을 수 있다. 
• 세션도 만료 시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.  

# HttpServer 클래스

HttpServer 클래스는 간단한 HTTP 서버를 구현한다. HttpServer는 IP 주소와 포트 번호에 바인딩되어 있으며, 이 주소에서 클라이언트로 들어오는 TCP 연결을 수신한다.  요청을 처리하기 위해 하나 이상의 HttpHandler 객체와 연관되어 있어야 하고 이는 HttpContext 객체를 통해 캡슐화를 할 수 있다.

• httpServer.create(InetSocketAddress addr, int backlog) => httpServer 인스턴스를 생성하고 주소를 바인딩한다. backlog는 연결 요청 대기 큐의 크기. 5가 되면 클라이언트 연결 요청을 5개까지 대기시킬 수 있다. 
• httpServer.createContext(String path, HttpHandler handler) => path에 대응하는 핸들러를 생성한다.

# InetSocketAddress 클래스 

InetSocketAddress는 IP Socket Address (IP address + port number)를 구현하고 pair (hostname + port number)도 구현 가능하며, 이 경우 호트스 이름을 확인하려고 시도한다. 

# HTTP Exchange

HttpExchange 클래스는 HTTP 요청을 캡슐화해서 수신하고 요청에 따라 응답을 생성해서 교환해준다. 전형적인 HttpExchange 라이프 사이클은 아래와 같다. 

• getRequestMethod() =>  요청 메서드를 받는다 
• getRequestHeaders()  => HTTP 요청 헤더에 있는 정보를 immutable Map으로 반환 받는다. 
• getRequestBody() => 요청 바디에 있는 정보를 stream을 통해 반환한다. stream의 모든 정보를 소화하고 stream을 닫는 것을 추천한다. TCP 컨넥션이 underlying해져서 다음 교환에 사용되지 못 할 가능성이 있기 때문.
• getResposeHeaders() => HTTP 응답 헤더에 있는 정보를 immutable Map으로 반환 받는다. 
• sendResponseHeaders() => 클라이언트에게 정해진 응답 헤더와 해당 요청의 응답 코드를 보낸다. 그리고 해당 응답 바디의 정확한 길이에 대한 정보도 나타날 수 있다.
• getResponseBody() => 응답 바디에 있는 정보를 stream을 통해 반환받고, 해당 메서드가 호출되기 이전에 sendResponseHeader가 먼저 호출이 되어야 한다. 

# HTTP request methods

HTTP는 요청 메서드를 정의해서 주어진 리소스에 수행하길 원하는 행동을 나타낸다. 

• GET 메서드는 특정 리소스의 표시를 요청한다. 오직 데이터를 받기만 한다. 
• HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문은 포함하지 않는다.
• POST 메서드는 특정 리소스에 엔티티를 제출할 때 사용된다. 서버 상태의 변화나 사이트이팩트를 일으킨다. => 리소스를 생성하기 위한 메서드로 요청한 횟수마다 새로운 리소스를 생성한다. 
• PUT 메서드는 특정 리소스가 없다면 생성하고 있다면 같은 리소스를 반환한다. 멱등하다.  전체를 수정한다
• PATCH 메서드는 수정만 담당하며 리소스의 일부만 수정할 때 사용한다. 
• DELETE 메서드는 특정 리소스를 삭제한다. 
• OPTIONS 메서드는 목적 리소스의 통신을 설정한다. 

# HTTP Response (Header, Body)

응답의 시작 줄은 상태 줄이라 불리며 다음과 같은 정보를 가지고 있다.

• 프로토콜 버전 : 보통은 HTTP/1.1 
• 상태 코드 : 요청 성공 여부를 나타낸다. 200, 404, 혹은 302이다. 
• 상태 텍스트 : 짧고 간결한 상태 코드에 대한 설명. SUCCESS, NOT FOUND 등 

응답에 들어가가는 상태 라인에 이어서 나오는 것은 메세지 헤더이며 두번째 줄 부터 빈 줄까지 계속된다. 주요 헤더는 아래와 같다.

• Cache-control : 브라우저가 패이짘를 캐쉬로 처리할 때 참고하라는 의미이며 no-cache로 지정할 경우 캐시하지 말라는 의미. no-cache는 로그인 페이지나 관리자 페이지등 중요한 페이지일 경우 설정 
• Content-Type : 서버가 보내는 컨텐츠의 형식을 표시하는 헤더로 정확히 설정되어아 브라우저가 컨텐츠 종류에 따라 적절하게 처리할 수 있다. charset=UTF-8은 컨텐츠의 인코딩이 어떻게 되어 있는지 지정한다. 
• Location : 서버의 응답이 컨텐츠가 다른 곳에 있다는 의미인 302임으로 Location 헤더를 통해 가야할 URL을 지정한다. 301이나 302 일 경우에만 볼 수 있다
• Server : 사용하는 웹 서버 소프트웨어의 종류와 버전을 표시한다. 

메세지 본문 : 

위와 같은 경우 HTML 파일 내용이 그대로 들어가 있으며 텍스트이므로 우리가 직접 읽을 수 있고, PNG나 GIF같은 이미지 파일이나 동영상 파일들은 바이너리 형식이므로 제대로 표시되지 않는다. 

# HTTP 응답 코드 (HTTP Status Code) 

HTTP Status Code는 서버에서 설정해주는 응답정보. 

• 1XX (조건부 응답)
  • 100 (계속) : 클라이언트는 요청을 지속해야 한다. 첫 번째 부분을 받았고 나머지 부분을 기다린다는 의미 
  • 101 (포로토콜 전환) : 클라이언트 서버에 프로토콜 전환을 요청했으며 서버가 승인 중이라는 의미 
• 2XX (성공) 
  • 200 (성공) : 서버가 클라이언트 요청을 제대로 수행했다는 의미 
  • 201 (생성) : 요청이 성공적이었고 새로운 리소스가 생성되었다는 의미. 일반적으로 POST, PUT 요청 이후에 온다
  • 204 (컨텐츠 없음) : 서버가 요청을 성공적으로 처리했지만 보내줄 컨텐츠가 없다 
• 3XX (리다이렉션) 
  • 300 (다중 선택) : 요청에 대해 하나 이상의 응답이 가능하다. 사용자는 그중 하나를 반드시 선택해야 한다. 
  • 301 (영구 이동) : 요청한 페이지를 새 위치로 영구적으로 이동했다는 의미 => 자동으로 새 위치로 전달된다
  • 302 (일시적 이동) : 요청한 리소스의 URI 가 일시적으로 변경되었음을 의미한다. 
  • 303 (기타 위치 보기) : 클라이언트가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 
  • 304 (수정되지 않음) : 마지막 요청 이후 요청한 페이지가 수정되지 않았다는 것을 의미한다 
• 4XX (요청 오류) 
  • 400 (잘못된 요청) : 서버가 요청의 구문을 인식하지 못하는 경우 
  • 401 (권한 없음) : 인증이 필요하다는 것을 의미 
  • 404 (찾을 수 없음) : 요청한 페이지를 찾을 수 없다. 
• 5XX (서버 오류) 
  • 500 (서버 처리 오류) : 서버가 처리 방법을 모른다는 의미 
  • 501 (구현되지 않음) : 요청 메서드를 인식하지 못 한다는 의미
  • 502 (Bad GateWay) : 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미한다. 
  • 503 (Service Unavailabe) : 서버가 요청을 처리할 준비가 되지 않았다는 의미. 유지보수 진행 중이거나 과부하가 걸렸을 때. 
  • 504 (Gatewayu Timeout) : 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어진다. 

# REST  

REST(Represeentatinal State Transfer) 는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처. REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌다. REST 기반 아키텍처를 따르는 API를 REST API라고 한다. 

# REST API 

REST의 가장 큰 특성은 각 요청이 어떤 동작이나 정보를 위한 것인지 그 요청의 모습 자체로 추론이 가능하다. 

즉, RESTful 하게 만든 API는 요청을 보내는 주소만으로 어떤 요청인지 파악이 가능핟고, 이러한 자원을 구조와 함께 나타내는 형태의 구분자를 URI라고 한다. 

쉽게 말하면 어떤 URI에 어떤 메서드를 사용할지 CRUD를 하나의 주소로 관리하자! 라는 의미 

 

REST API 요청을 보낼 때는 HTTP 규약에 따라 신호를 전송한다. 

REST API는 주로 HTTP 메서드인 GET / POST / DELETE / PUT / PATCH를 사용한다.

# RESTful 

RESTful은 일반적으로 REST 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이고 REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다. RESTful은 REST를 REST답게 쓰기 위한 방법. 

 

RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이고 RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이다. 

# OSI 7 계층 

https://ddurubird.tistory.com/109

# TCP / IP 

TCP/IP는 네트워크 프로토콜 스위트로, 온라인 상 안전하고 효율적인 데이터 전송의 필수요건을 정의한다.  TCP/IP 모델은 두 개의 기기 간에 데이터를 전송하는 것을 담당하고 있다. 수백 대의 컴퓨터 사이에서 활발하게 데이터가 공유되고 있는 것처럼 보여도, 사실은 모든 데이터 교환에는 2대의 기기만 개입한다. TCP/IP는 4계층 또는 5계층으로 구성되어 OSI 7계층 모델을 대체한다. 

 

TCP 프로토콜 : 전송제어 프로토콜 (Transmission Control Protocol)의 약자이며 한 기기에서 다른 기기로 데이터를 전송하는 것을 담당한다. 

IP 프로토콜 : 인터넷 프로토콜 (Internet Protocol)의 약자이며 이 프로토콜은 데이터의 조각을 최대한 빨리 대상 IP 주소로 보내는 역할을 한다. 

 

# TCP/IP 4계층

응용 계층( Application Layer) :  http ~

• 응용계층 (Application Layer) 프로토콜은 TCP / IP 프로토콜 범위에 포함되어 있다. 이러한 프로토콜은 앱에 구축되기 때문에 사용자가 상호작용하기 가장 쉬운 계층이다. 응용계층은 사용자가 네트워크에 접근할 수 있도록 한다. 게다가 사용자 인터페이스를 제공할 뿐만 아니라 이메일, 원격 파일 접근 등 서비스를 제공한다. 
• 메일 프로그램 SMPT, 인터넷 브라우저는 웹 서버와 사용자의 인터넷 브라우저 사이에 문서를 전송하기 위해 사용되는 통신 규약인 HTTP, 파일 전송 규약 FTP 등이 있다. 

전송 계층 (Transport Layer):  tcp , udp

• 전송 계층은 전송을 담당한다. 전송 계층에는 TCP 뿐만 UDP도 있다. UDP는 TCP보다 단순하며 다른 데이터에 비해 안전하게 보호되어야 할 필요가 없는 실시간 응용 프로그램에서 흔히 사용된다. UDP는 TCP보다 신뢰도가 낮고 오류 검출, 흐름 제어 등의 기능을 제공하지 않아 패킷을 빠르게 전송하는 응용 계층에서 이용된다. 
• TCP는 두 네트워크 사이에 연결을 형성하고 효율적인 작업을 위해 데이터를 작은 패킷으로 나눠서 전송한다. TCP는 연결형 서비스지만 UDP는 비연결형 서비스다. TCP에서 전송 순서를 보장하지만 UDP의 경우 전송 순서가 바뀔 수 있다. 

인터넷 계층 (Internet Layer): ip

• 인터넷 계층 프로토콜에는 IP 뿐만 아니라 주소 변환 규약 (ARP) 등이 있고, 인터넷 계층은 네트워크 간 데이터 패킷의 전송을 관리한다. ICMP 인터넷 제어 메세지 프로토콜도 있다.  
• ARP는 네트워크 계층 주소와 링크 계층 주소 사이의 변환을 담당하는 프로토콜이고, ICMP는 인터넷 통신 서비스 환경에서 오류에 대한 알림과 관련된 메세지를 전달하는 목적의 프로토콜이다. 

데이터 링크 계층(Datalink Layer) : MAC  

• 데이터 링크 계층은 데이터 전송의 최하위 계층으로 네트워크 인터페이스 계층이라고도 불린다. 이 계층에서 하는 일은 데이터가 원하는 IP주소에 도달할 뿐만 아니라 해당 네트워크 내의 연결된 기기에 연결되어 있는지 확인하는 역할을 한다. 데이터 링크 계층은 원하는 기기의 MAC 주소를 확인하고 이더넷 케이블 및 와이파이를 통한 데이터 전송을 관리하는 작업을 한다. 

# HTTP /2 

HTTP /2는 속도 향상을 위해 많은 개선이 있었다. 크게 5가지가 있다. 

 

1. 멀티 플렉싱 (Multiplexing)

HTTP/1.1은 Persistent와 Pipelining 기능을 통해 하나의 TCP 세션에 여러개의 요청을 보낼 수 있다. 다만 요청은 반드시 순처적으로 서버에서 처리되어 브라우저로 전달되어야 한다. 따라서 웹페이지 접속 지연이 발생되며 이를 HOLB (Head of LIne Blocking)이라 한다. 

HTTP/2의 멀티 플렉싱은 하나의 TCP 커넥션만으로 해당 웹페이지의 모든 요청과 응답 데이터를 전송하며, 바이너리 프레임의 스트림 전송 방식을 통해 응답 순서에 무관하게 데이터를 처리한다. 

 

2. 헤더 압축 (Header Compression) 

HTTP/1.1 은 요청과 응답에 헤더를 이용해 여러 기능을 지원한다. Host 헤더를 이용하면 가상 호스팅을 가능하게 하고, Refer 헤더를 통해 어느 경로로 사이트를 접근했는지 알 수 있고, User-agent 헤더를 이용해 사용자 환경을 조사할 수 있지만 요청/응답마다 같은 정보를 반복해서 전달해야 하는 비효율적인 측면이 존재해서 중복된 내용이 있는 헤더의 경우 내용을 압축해서 적은 비트를 이용해 표현이 가능하게 했다. 

 

3. 서버 푸쉬 (Server Push)

클라이언트가 main.html을 요청하면 HTTP/1.1은 main.html의 응답을 받고 main.html 안에 링크되어 있는 css, js, jp등 소스를 추가로 요청하고 모든 컨텐츠가 전송되면 main.html 페이지를 브라우저에서 보여주게 된다. 

HTTP/2는 main.html을 요청하면 서버는 main.html 구성 요소에 css, js, jpg 리소스가 있는 경우 main.html 응답을 전송할 때 모두 같이 전송해서 HTTP 트랜잭션은 4개에서 1개로 줄기 때문에 응답속도가 개선되었다. 

 

4. 우선 순위 (Stream Prioritizaion)

HTTP/1.1 에서는 웹페이지 렌더링에 대해 효과적으로 할 수 있는 옵션이 없었고, css와 jpg 전달되는 과정에서 css가 느리게 전달되는 경우 페이지 렌더링에 지연이 발생됐다. HTTP/2 에서는 우선순위를 정의해서 렌더링 지연을 최소화 할 수 있다. 

 

5. 보안 통신 (HTTPS) 

HTTP/2는 보안 접속을 기본으로 한다.

# 프록시 (Proxy)  

컴퓨터 과학적인 의미로는 프로토콜 상에서 무언가 대신하는 것을 의미하고, 프록시 서버는 클라이언트에서 서버로 접속 할 때 직접적으로 접속하지 않고 중간에 대신 전달해주는 서버를 의미한다. 아래와 같이 진행된다.

• 클라이언트에서 프록시 서버로 전달할 요청을 보낸다 
• 프록시 서버는 클라이언트로부터 전달 받은 요청을 서버에 요청한다 
• 서버는 요청에 맞게 데이터를 프록시 서버로 전달한다
• 프록시 서버는 서버로부터 전달 받은 데이터를 클라이언트에 전달한다. 

프록시가 필요한 이유 : 

• 보안 : 서버의 IP를 숨기는 것이 가능하고 이는 외부로부터 위험을 막아주는 역할을 한다. 
• 캐시 : 이전에 했던 요청들을 프록시 서버에 캐싱해두어 다음 번에 재요청을 보낼 때 서버를 거치지 않고 데이터를 주고 받을 수 있기 때문에 속도가 빨라진다 
• 우회 : 클라이언트에서 서버의 주소를 감출 수 있기 때문에 어느 곳에서 접속한지를 숨길 수 있다. IP를 통해 접속을 감지하는 사이트를 프록시 서버를 통해 우회할 수 있다. 

포워드 프록시 :

클라이언트 대신 프록시 서버가 목적 서버에 통신을 해주는 구성을 포워드 프록시라고 한다. 클라이언트는 프록시 서버만을 통해 정보를 얻게 된다. 

 

리버스 프록시 :

리버스 프록시는 web서버 쪽에 위치하여 클라이언트의 접근을 최초로 받아 리퀘스트에 해당하는 web서버에 배분해주는 역하을 한다

• 로드 벨런싱 
• 캐싱 
• 보안, 바이러스 대책

# URL과 URI 

• URI : 통합 자원 식별자 (Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소. URI의 존재는 인터넷에서 요구되는 기본조건으로 인터넷 프로토콜에 항상 붙어 다니고 하위 개념으로는 URL, URN이 있다. 
• URL : 유일 자원 지시기(Uniform Resource Locator)은 네트워크 상에 자원이 구체적으로 어디 있는지 알려주기 위한 규약이다. 즉, 컴퓨터 네트워크와 검색 매커니즘에서 위치를 지정하는, 웹 리소스에 대한 참조. 
• URN: 통합 자원 이름(Uniform Resource Name)은 컨텐츠를 이루는 한 리소스에 대해, 리소스 위치에 영향 받지 않는 유일무이한 이름 역할을 한다. 위치에 독립적인 URN은 리소스 위치를 옮기더라도 문제 없이 작동하고 여러 프로토콜로 접근해도 문제가 없다. 

 

URI과 URL의 차이 

• URI => http://www.google.com/index  => index라는 자원 식별자에는 index.html가 있었을 뿐 다른 문서가 들어갈 수 있다. => 참조 변수와 비슷하다고 이해를 했다.
• URL => htts://www.google.com/index.html => index.html 위치를 나타내는 정확한 주소 => 이건 원시타입 변수 절대적이다.

 

예시 :

추가 설명 :

https://johngrib.github.io/wiki/URI/

 

• URI는 식별자일 뿐이다.
• URL은 주소의 디레퍼런싱이 가능한 식별자이다. 

# 프로토콜(protocol)

포로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계이다. 기기 간 통신은 교환되는 데이터의 형식에 대해 상호 합의를 요구한다.

• 프로토콜의 기본 요소
  • 구문(Syntax) : 전송하고자 하는 데이터의 형식(Format), 부호화(Coding), 신호 레벨(Signal Level) 등을 규정
  • 의미(Semantics) : 두 기기 간의 효율적이고 정확한 정보 전송을 위한 협조 사항과 오류 관리를 위한 제어 정보를 규정
  • 시간(Timing) : 두 기기 간의 통신 속도, 메시지의 순서 제어 등을 규정

# 통신 프로토콜 

통신 프로토콜은 컴퓨터나 원거리 통신 장비 사이에서 메세지를 주고 받는 양식과 규칙의 체계. 

# 노드 (Node)

일반적으로 네트워크에 연결된 모든 물리적인 기기 또는 장치를 노드라고 한다. 즉 네트워크 상에서 데이터를 주고 받을 수 있는 PC, 노트북, 스마트폰 등 모두 하나의 노드이다.

노드는 네트워크에서 데이터를 전송하기 위한 연결된 기기이기 때문에 데이터를 보내는 송신지 또는 데이터를 받는 수신지 역할을 한다. 따라서 데이터를 주고 받는 노드에도 다른 노드와 구별할 수 있는 고유한 주소가 필요하고, 다른 노드와 구별되는 고유한 주소를 갖고 있는 노드를 네트워크에 연결된 주소가 있는 물리적인 장치라고 정의한다. MAC라는 고유한 물리 주소를 갖는 컴퓨터와 라우터가 대표적인 노드.

# 호스트(host) 

노드 중에서 애플리케이션을 실행할 수 있는 컴퓨팅 시스탬을 갖춘 기기를 호스트라고 한다. 쉽게 말하면 호스트는 네트워크에 연결된 컴퓨터. 따라서 호스트는 사용자가 애플리케이션을 실행해서 네트워크에 접속할 수 있는 창구 역할을 한다. 호스트는 인터넷에서 사용하는 IP 주소가 할당되기 때문에 다른 말로 IP로 식별되는 노드라고 표현한다. 

 

*호스트 사이에서 제공되는 서비스를 기준으로 호스트를 세분화해서 서비스를 제공하는 호스트를 서버, 서비스를 요청하고 사용하는 호스트를 클라이언트라고 한다. 

# 포트(port)

• 포트란 IP 내에서 애플리케이션 상호 구분을 위해 사용하는 번호. 서버의 응답이 어떤 포트에게 전달되는지 정함.
• 포트 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로를 의미한다. 
• 이미 사용 중인 포트는 사용할 수 없다. 
• 포트는 0 ~ 65,535까지 사용할 수 있다. 그 중 0 ~ 1024번 까지 포트 번호는 통신 규약에 따라 이미 정해져있다. 
• SSH : 22 , HTTP : 80, HTTPS: 443

# path(경로)

path란 파일시스템을 통해 특정 파일에 이르는 경로를 말한다.

#패키지

패키지란 클래스의 모음집입니다.  패키지를 통해서 라이브러리끼리 구분할 수 있습니다. 

패키지를 사용하는 이유는 클래스 명의 고유성을 보장하기 위함.

# 추상 메서드 

• 추상 메서드 선언은 해당 메서드가 클래스의 멤버라는 것과, 메서드 시그니처, 리턴타입 throw에 대한 정의는 하지만 구현은 제공하지 않는다. 
• 추상 메서드가 아닌 메서드는 쿠체 메서드라 할 수 있다
• 추상 메서드 M은 반드시 추상 클래스 내에 직접 선언되어야 한다, 그렇지 않으면 컴파일 에러가 난다 
• 추상 클래스가 아닌 모든 서브 클래스는 반드시 추상 메서드 M의 구현을 제공해야 한다. 
• 추상 클래스에서 또 다른 추상 메서드 선언을 제공하면 메서드 오버라이드를 할 수 있다. 

# 추상 클래스, 인터페이스 

추상 클래스 : 

하나 이상의 추상 메서드를 갖는 클래스, 추상 클래스는 추상 메서드를 선언해서 상속을 통해 자손 클래스에서 완성하도록 유도하는 클래스이다. 미완성 설계도라고 표현한다. 상속을 위한 클래스이기 때문에 따로 인스턴스를 생성할 수 없다. 

추상 클래스는 자신의 기능을 하위 클래스로 확장 시키는 느낌. is a kind of

• 관련성이 높은 클래스 간에 코드를 공유하고 싶은 경우 
• 추상 클래스를 상속 받을 클래스들이 공통으로 가지는 메서드와 필드가 많거나 public 이외 다른 접근자 선언이 필요한 경우 

 

인터페이스 : 

인터페이스도 추상 클래스와 비슷하나, ㅈ인터페이스에 정의된 메서드를 각 클래스의 목적에 맞게 기능을 구현 하는 것. 설계도로 인한 기능의 확장. be able to 

• 서로 연광성이 없는 클래스들이 인터페이스를 구현하는 경우 
• 특정 데이터 타입의 행동을 명시하고 싶은데 어디서 그 행동이 구횐되는지 신경 

# template method pattern 

템플릿 메서드 패턴은 Behavior 패턴으로 여러 작업들이 완전히 동일한 단계를 갖지만, 일부 동작은 각각 다르게 구현해야할 때 사용되는 패턴이다. 템플릿 메서드 패턴은 아래와 같이 두가지로 나뉜다. 

• 실행 과정을 구현한 상위 클래스 (추상 클래스) 
• 실행 과정 일부 단계를 구현한 하위 클래스 (구체 클래스) 

상위 클래스는 작업의 전체 흐름을 구현한다. 즉, 상위 클래스가 흐름 제어의 주체가 된다. 그리고 각 구현체별 다르게 구현해야하는 일부 동작은 추상 메서드로 따로 정의한 다음. 그 추상 메서드를 호출하는 방식으로 구현하게 된다. 하위 클래스는 다르게 동작해야하는 부분. 즉 추상 메서드만 재정의하면 된다. 

# MVC  패턴 :

Model : 데이터와 관련된 책임을 담당하는 레이어 

• [POJO] 비즈니스 로직을 수행한다
• 주로 상태 변화를 처리한다 (최근에는 엔티티, VO, Aggregate로 나눠서 관리) 
• 엔티티(영속성에서 테이블에 매핑되는 클래스가) 주로 대상이다 
• 데이터와 행동을 갖는 객체 

View : 사용자에게 보일 사용자 인터페이스를 담당하는 레이어 

• 웹에서는 웹 브라우저로 렌더링 되는 페이지가 해당한다 
• 모델이 처리한 데이터를 받아서 합산하고 사용자의 브라우저로 렌더링 되는 레이어 
• 데이터, 로직이 없어야 한다 -> 상황과 도메인에 맞게 다른 값을 가져야 하는 데이터들에 대해서만 모델에서 받아온다
• 동적으로 처리되어야 할 데이터를 시각화해준다  

Controller: Model과 뷰를 연결해주는 레이어 

• 컨트롤러는 상용자의 요청에 맞는 서비스를 실행하게 된다(모델에서)
• 처리한 모델의 값을 뷰에 전달해서 반환한다 
• 사용자의 요청(뷰로 부터) 가장 먼저 마주한다 
• 컨트롤러를 제외한 레이어(모델, 뷰)는 다른 레이어를 알아서는 안된다. 

MVC 패턴 원칙 : 

• 모델은 컨트롤러와 뷰에 의존해선 안된다. 오로지 데이터에 대한 순수 로직만 존재하는 것이 바람직하다 
• 뷰는 모델에만 의존한다. 뷰에서 사용되는 값은 모델에서 전달된 값이여만 한다. 컨트롤러가 모델에 대한 값을 뷰에 전달해준다 
• 뷰는 모델로부터 사용자마다 다르게 변경되는 데이터를 받아야 한다 
• 컨트롤러는 모델과 뷰에 의존해야 한다. 컨트롤러는 들어온 요청에 맞게 모델의 로직을 호출하고 (Service를 통해) 그 결과를 뷰로만 전달한다. 
• 뷰가 모델로 부터 데이터를 받을 때는 컨트롤러에서 받아야 한다  

# 레이어드 아키텍처( Service, Model, Repository)  

레이어드 아키텍처는 코드를 논리적인 부분 혹은 역할에 따라 독립된 모듈로 나누어서 구성하는 패턴이다. 

각 레이어는 다음과 같은 클래스로 구현된다. 

 

Presentation layer: Controller 

Presentation layer는 해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 열결되는 부분. 웹사이트에서 UI 부분에 해당하고 백엔드 API 에서는 엔드포인트 부분에 해당한다. 뷰나 엔드포인트들을 정의하고 전송된 HTTP 요청을 읽어 들이는 로직을 구현한다. 

 

Business layer : Service 

Business layer는 비즈니스 로직을 구현하는 부분. 실제 시스템이 구현해야 하는 로직을 이 레이어에서 구현하게 된다.  단순 도메인이 반환한 결과를 컨트롤러에 전송하는 역할로 보이지만, 여러 도메인 객체를 조합해서 결과를 만들어 반환하거나 기타 다른 여러 비즈니스 로직을 구현한다. 

 

Persistence Layer : Repository 

데이터 베이스에 접근하는 계층이다. 비즈니스 요청 처리에 따라 데이터베이스에서 데이터를 저장하거나 조회, 삭제 등 로직을 수핸한다. 

영속성 작업을 수행하기 위해 일반적인 컬렉션과 비슷한 인터페이스를 가지고 DB에 대한 구현 의존성을 줄이고 Infra layer를 객체지향적으로 바라볼 수 있게 해준다. 

 

Database Layer : Database 

DB로 부터 요청/응답 처리. 

# 삼항연산자 

int bar = 0; 

boolean asnwer; 

answer = bar == 0 ? true : false; 

answer == true; 

# Collection 

https://ddurubird.tistory.com/65 Collection 부분 참고 

# Stream API 

Stream은 자바 8버전 부터 추가된 컬렉션(배열) 의 저장요소를 하나씩 참조해서 람다식으로 처리할 수 있도록 도와주는 반복자. 람다식으로 요소 처리 코드를 제공하고 내부 반복자를 사용하기에 병렬 처리가 쉽고 중간처리 + 최종 처리의 파이프라인 작업을 수행한다(지연연산) 

• 내부 반복자 : 내부 반복자는 컬렉션 내부에서 요소들을 반복시키고, 개발자는 요소당 처리해야할 코드만 제공하는 패턴 
• 병렬 처리 : 병렬 처리는 한 가지 작읍을 서브 작업으로 나누고, 서브 작업들을 분리된 스레드에서 병렬적으로 처리하는 것. 병렬 처리 스트림을 이용하면 런타임 시 하나의 작업을 서브 작업으로 자동으로 나누고, 서브 작업의 결과를 자동으로 결합해 최종 결과물을 생성한다. 
• 중간처리와 최종처리 : Stream은 데이터를 가공하는 중간 처리와 결과물을 내는 역할을 하는 최종 처리 파이프라인으로 이루어져있다. 또한 Stream은 해당 데이터로 최종 처리를 해야만 중간 처리 과정을 수행한다. 즉 최종 처리 전까지는 연산을 미루는 지연되는 성격을 가지고 있다. 

스트림 동작 순서 

# Optional 

Optional은 주로 결과 없음(no result)를 나타낼 필요가 있고 null을 사용하면 오류가 발생할 수 있는 메서드의 리턴 타입으로 사용하기 위해 사용된다. Optional 타입인 변수는 절대 null이 아니어야 하고 항상 Optional 인스턴스를 가리켜야 한다. 

• Optional 클래스는 제네릭 타입으로 제공된다 -> 선언과 동시에 타입 매개변수를 지정한다
• Optional 객체를 만들기 위한 정적 팩토리 메서드가 제공된다 
• Optional.empty() -> 비어있는 Optional 객체를 생성한다. 비어있다는 의미에서 null과 비슷하지만 참조를 해도 NPE가 발생하지 않는다 
• Optional.of(T value) -> null이 아닌 값을 감싸는 Optional 객체를 생성한다 -> null을 감싸면 NPE 발생 

# 의존성 주입 (Dependency Injection)

의존성이란 한 객체에서 다른 객체를 가져다 사용하면 의존성이 있는 것이다. A와 B가 존재하고 B가 변경될 때 A도 변경되어야 하면 A가 B에 의존성을 가진다고 한다. 

• 의존성 주입은 필요한 자원을 외부에서 생성자를 통해 넣어주는 것. 
• SimpleMovieLister 내부에서 new MovieFinder()를 해서 직접 객체를 만들어버리는게 의존성 주입과는 반대 
• 생성자를 통해서도 가능하고 settter를 통해서도 가능하다 

의존성 주입이 중요한 이유 : 

만약 MovieFinder가 인터페이스고 MovieFInder를 구현한 HorrorMovieFinder 클래스가 있다고 가정하자. 그럼 SimpleMovieFinder 안에서 MovieFinder변수를 resolve하려면 아래와 같이 된다. 

근데 이렇게 SimpleMovieLister 안에서 구체적인 타입이 결정되어 버리면 SimpleMovieLister는 MovieFinder라는 인터페이스 자체가 아니라 HorrorMovieFinder와 의존성을 갖게 된다. 즉, 구체적인 구현에 의존하게 되어 다른 MovieFinder 구현체를 사용하기 위해서는 코드를 수정해야 한다 => 이는 OCP 원칙에 위배된다. 따라서 DI를 사용해 구체적인 구현이 아닌 인터페이스에 의존하게 해야 한다.  

# 깊은 복사와 얕은 복사 

얕은 복사는 주소값을 복사한다. 즉 참조타입인 경우 참조하고 있는 실제 값은 같다.  ArrayList.clone()은 얕은 복사.

깊은 복사인 경우 실제값을 새로운 메모리 공간에 복사한다. 

 

객체의 깊은 복사를 구현하는 방법은 3가지가 있다. 

 

1. 복사생성자 or 복사팩터리 

2. 직접 객체를 생성해서 복사 

3. Cloneable을 구현하여 clone() 재정의. 배열인 경우에만 추천. 대상 객체에 cloneable을 구현하고, clone()메서드를 override해서 ArrayList 안의 각각 객체들을 clone()해주면 된다.