배움을 기록으로

코딩 테스트시 자주 틀리는 부분 정리

• int형의 범위는 21(10의 9승)억이므로, 21억이 넘어갈 시, long형(10의 18승) 사용
  • https://www.acmicpc.net/problem/16953
  • https://www.acmicpc.net/problem/2012

• DFS는 재귀함수 사용하는게 간단함, 스택 사용시에는 PUSH할 때 출력하고, 끝에 도달했을 때 POP(flag사용)
  • https://www.acmicpc.net/problem/1260

• 재귀 or 백트래킹시, 순열이 아닌 조합 케이스인 경우 index값을 시작값으로 해야 시간초과 발생 X
  • https://www.acmicpc.net/problem/14889

제이쿼리로 개발시, $(document).ready 나 $(window).load 함수를 자주 사용하게 되는데

두 함수의 차이점과 각각 언제 사용해야 하는지를 정리하고자 한다.

1. 웹 브라우저의 HTML 문서 렌더링 과정

'브라우저는 HTML 파일을 어떤 순서로 읽어올까?'

1. 사용자가 웹 페이지 방문
2. 웹 브라우저가 웹 문서를 읽기 시작
3. DOM 생성
4. ready 메소드 실행
5. 이미지를 포함한 요소들이 로드
6. load 메소드 실행
7. 페이지 로딩 완료

2. $(document).ready 와 $(window).load 차이

1.1.  $(document).ready

• 외부 리소스, 이미지와는 상관없이 브라우저가 DOM(document object model) 트리 생성 직후, 실행되는 콜백함수
• 중복 사용이 가능하고, 선언한 순서대로 실행
• 모든 리소스가 로드될 때까지 기다리고 동작하면 비효율적이므로, 일반적인 스크립트 동작은 ready에서 실행한다.
  
  

1.2.  $(window).load

• 페이지의 모든 요소(css, js, image ..)들이 로드된 이후에 호출되는 콜백함수
• 한 페이지에 하나의 함수만 적용된다. (가장 나중에 호출된 함수만 적용)
• 리소스 정보에 따른 이벤트 분기가 필요한 경우 사용한다.
  • 예시: 이미지 크기에 따른 분기 동작이 필요한 경우
    
    

1.3.  정리

• ready는 사용자에게 보여지는 화면이 그려지기전, load는 그려진 후에 실행
• DOM 생성 -> $(document).ready() -> 이미지를 포함한 요소들이 로드 -> $(window).load()
• ready는 중복 가능, load는 중복 불가

'다음 소스는 어떤 순서로 실행될까?'

<script type="text/javascript">
$(window).load(function() {
	console.log('1');
});

$(window).on('load', function () {
	console.log('2');
});

$(document).ready(function() {
	console.log('3');
});

$(document).ready(function() {
	console.log('4');
});
</script>

• 실행순서 : 3 > 4 > 2
• $(window).load() 와 $(window).on('load', function() {})은 같다.
• load()는 마지막 하나만 실행
• $(document).ready() 와 $(function(){})은 같다.

References

https://truecode-95.tistory.com/30

https://ojtiger.com/179

6. HTTP 상태코드

6.1. 상태코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
  
  • 1xx (Information): 요청이 수신되어 처리중
  • 2xx (Successful): 요청 정상 처리
  • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 (리다이렉션)
  • 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
  • 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

'HTTP 상태코드 값을 전부 외워야 할까?'

• 클라이언트는 상위 코드로 해석해서 처리
• 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨
• 예)
  • 289 -> 2xx (요청이 성공 했구나~)
  • 455 -> 4xx (클라이언트에서 잘못 요청했구나~)
  • 598 -> 5xx (서버쪽에 오류가 있구나~)

'리다이렉션(Redirection)이란?'

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
• 흐름
  1. 요청 (/notice)
  2. 응답 (Location: /new-notice)
  3. Location URL로 자동 리다이렉트
  4. 요청 (/new-notice)
  5. 응답 (200 OK)
• 종류
  • 영구 리다이렉션 (특정 리소스의 URI가 영구적으로 이동)
    • 보통 URL 주소가 변경된 경우, 이전 URL로 들어오는 유입에 대해 변경된 주소로 리다이렉션하여 처리 
    • 예) /main -> /home
  • 일시 리다이렉션 (일시적인 변경)
    • 요청 처리 후, 다른 페이지로 이동시키는 경우로, 클라이언트의 중복 요청을 방지한다.
    • 클라이언트의 URL이 리다이렉트된 URL로 변경된다. (새로고침시 중복 요청 방지)
    • PRG: Post / Redirect / Get
    • 예) 주문요청 (Post) > 주문 완료페이지로 리다이렉션(Redirect) > 주문 완료페이지 이동 (Get)
            (주문 요청을 여러 번 하더라도, 주문완료 페이지만 GET으로 호출됨.)
  • 특수 리다이렉션
    • 결과 대신 클라이언트에 있는 캐시를 사용

[ 1xx (Informational)  ]

• 요청이 수신되어 처리중인 상태
• 거의 사용하지 않는다.
  
  

[ 2xx (Successful)  ]

• 클라이언트의 요청을 성공적으로 처리
• 종류
  • 200 OK (요청 성공)
  • 201 Created (요청 성공해서 새로운 리소스가 생성됨)
  • 202 Accepted (요청이 접수되었으나 처리가 완료되지 않았음)
    • 배치 처리 같은 곳에서 사용
    • 예) 배치 요청 접수 성공 후, 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우
  • 204 No Content (서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음)
    • 저장 후에 아무 내용이 없어도 된다.
    • 보통 저장 후에 같은 화면을 유지해야 하는 경우 사용
    • 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있는 경우

[ 3xx (Redirection)  ]

• 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
• 종류
  • 300 Multiple Choices (안쓴다)
  • 301 Moved Permanently
    • 영구 리다이렉션
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
      (POST로 요청해도,  GET으로 리다이렉트)
  • 302 Found
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
      (원래 스펙은 메서드 유지지만, 통상적으로 GET으로 변경됨)
  • 303 See Other
    • 302와 기능은 같음
    • 리다이렉트시 요청 메서드가 GET으로 변경
  • 304 Not Modifield
    • 캐시 목적으로 사용
    • 리소스가 수정되지 않았음을 알려주고, 클라이언트에 저장된 캐시를 재사용하도록한다 (캐시로 리다이렉트)
    • 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
    • 조건부 GET, HEAD 요청시 사용
  • 307 Temporary Redirect
    • 302와 기능은 같음
    • 리다이렉트시 요청 메서드와 본문 유지
  • 308 Permanent Redirect
    • 301과 기능은 같음 (영구 리다이렉션)
    • 리다이렉트시 요청 메서드와 동일하게 분문 유지 (POST로 요청했을때 POST로 리다이렉트)
      
      
      

'302, 307, 303 상태코드는 서로 비슷한데 뭘 써야할까?'

• 302, 307, 303
  • 302 Found: GET으로 변할 수 있음 (May)
  • 307 Temporary Redirect: 메서드가 변하면 안됨 (유지)
  • 303 See Other: 메서드가 GET으로 변경 (변경)
• 히스토리
  • 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것
  • 하지만 통상적으로 브라우저에서 GET으로 바꿔서 사용하였음
  • 그래서 기존에 영향을 안주면서 명확한 상태코드인 307, 303이 등장 (301 대용으로 308도 등장)
• 이미 많은 애플리케이션들이 302를 기본값으로 사용하므로 GET으로 변해도 302를 사용하여도 큰 문제 없음

[ 4xx (Client Error)  ]

• 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같이 재시도를 하면 실패함 (5xx와 차이점)
• 종류
  •  
  • 400 Bad Request (클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음)
    • 요청 구분, 메시지 등 오류
    • 클라이언트는 요청 내용을 검토해서 다시 보내야함
    • 예) 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을때
           (필수 요청 파라미터 누락, 미성년자 주류 구매, 로그인시 비밀번호 틀린 경우)
  • 401 Unauthorized (클라이언트가 해당 리소스에 대한 인증이 필요함)
    • 해당 리소스에 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않은 경우
    • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
    • 예) 사용자가 로그인되지 않은 경우
  • 403 Forbidden (서버가 요청을 이해했지만 승인을 거부함)
    • 주로 인증 자격 증명은 있지만(인증), 접근 권한이 불충분한 경우(인가)
    • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
    • 예) 일반 사용자가 로그인하여(인증), 관리자 등급의 리소스에 접근하는 경우(인가)
  • 404 Not Found
    • 요청 리소스를 찾을 수 없음
    • 클라이언트가 권한이 부족한 리소스에 접근할 때(403 케이스), 해당 리소스를 숨기고 싶을때 사용하기도 함
    • 예) 잘못된 URL 요청 (www.naverrr.com)

[ 5xx (Server Error)  ]

• 서버 오류
• 서버에 문제가 있기 때문에 재시도하면 성공할 수도 있음 (복구가 되거나 등, 400에러와 차이점)
• 종류
  • 500 Internal Server Error (서버 문제로 오류 발생, 애매하면 500 오류)
    • 서버 내부 문제로 오류 발생
    • 예) 서버 사용량 폭주로 서비스가 일시 중단, 문법적 오류 (NullPointException), DB 접속 실패 등
  • 503 Service Unavailable (서비스 이용 불가)
    • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
    • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

https://developer.mozilla.org/ko/docs/Web/HTTP/Status/401

프로젝트에 처음 투입되어 개발환경을 세팅할 때, 서버나 DB 접속 정보가 정확한 경우에도

연결이 안되는 경우가 종종 발생하곤 한다.

이런 경우, 보통 방화벽이 막혀있는 경우가 대다수이며 방화벽 차단 여부를 확인하기 위해

telnet 명령어를 주로 활용한다.

윈도우의 경우 telnet 명령어를 사용하기 위해서는 간단한 설정이 필요하여 해당 포스팅을 통해

telnet 활성화 방법 및 telnet, ping 명령어의 사용법 등을 정리하고자 한다.

1. TELNET

1.1. 개념

'텔넷(telnet) 이란?'

• 텔넷(telnet)은 인터넷이나 로컬 영역 네트워크 연결에 쓰이는 네트워크 프로토콜
• 보통 해당 포트(Port)에 접속 가능한지 확인하는 용도로 사용
• 예) DB connection 에러, 원격 접속 실패 등

telnet [IP] [PORT]
예) telnet 142.250.206.206 443

1.2. 텔넷 활성화 (Windows 10 기준)

• 윈도우에서는 텔넷을 활성화하지 않고, 텔넷 명령어 실행이 불가하다.

• 시작메뉴 > Windows 기능 켜기/끄기 실행
  (제어판 > 프로그램 > 프로그램 및 기능 > Windows 기능 켜기/끄기)

• 텔넷 클라이언트 기능 활성화

• 다시 telnet 명령어 실행하여, 텔넷 활성화 여부 확인

1.3. 텔넷 사용법 (Windows 10 기준)

• '시작메뉴' 또는 '윈도우즈키 + R'로 실행창 실행 후 '명령 프롬프트' 실행

• telnet 실행

2. PING

2.1. 개념

'IP 접속 가능 여부만 확인하고 싶을 때는?'

• ping은 IP 네트워크를 통해 특정한 호스트가 도달할 수 있는지의 여부를 테스트
• 네트워크 상태를 점검하는 가장 기본적인 명령어
• 패킷을 보낸 후 대상 컴퓨터가 이에 대해 응답하는 메시지를 보내면 이를 수신, 분석하여 대상 컴퓨터가 작동하는지,
  또는 대상 컴퓨터까지 도달하는 네트워크 상태가 어떠한지 파악

ping [IP 또는 도메인] [옵션]
예) ping 142.250.206.206 -a

2.2. 핑(ping) 사용법

• 텔넷과 동일하게 cmd 창에서 진행
• 텔넷처럼 활성화가 따로 필요하지는 않다.
  

References

https://taewooblog.tistory.com/130

https://server-talk.tistory.com/53

5. HTTP 메서드 활용

5.1. 클라이언트에서 서버로 데이터 전송

'데이터 전달 방식은 크게 2가지!'

• 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 주로 정렬 필터(검색어)
• 메시지 바디를 통한 데이터 전송
  • POST, PUT, PATCH
  • 회원가입, 상품주문, 리소스 등록, 리소스 변경

'데이터 전송 케이스는 크게 4가지!'

• 정적 데이터 조회
  • 이미지, 정적 텍스트 문서
  • GET 메서드 사용
  • 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
    
    
• 동적 데이터 조회
  • 주로 검색, 게시판 목록에서 정렬 필터(검색어)
  • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 조건에 주로 사용
  • GET 메서드 사용
  • GET은 쿼리 파라미터를 사용하여 데이터 전달
  • 예) https://www.google.com/search?q=인프런
    
    
• HTML, Form을 통한 데이터 전송
  • HTML Form submit시 POST 전송
    • 예) 회원가입, 상품주문, 데이터 변경
  • Content-Type: application/x-www-urlencoded 사용
    • form의 내용을 메시지 바디를 통해서 전송 (key=value, 쿼리 파라미터 형식)
    • 전송 데이터를 urlencoding 처리 (서버에서 decoding이 필요할 수 있음)
      • 예) abc김 -> abs%EA%B9*80 
  • HTML Form은 GET 전송도 가능
  • Content-Type: multipart/form-data
    • 파일 업로드 같은 바이너리 데이터 전송시 사용
    • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능 (그래서 이름이 multipart)
  • 참고: HTML Form 전송은 GET, POST만 지원
    
    
• HTTP API를 통한 데이터 전송
  • 예) 회원가입, 상품주문, 데이터 변경
  • 서버 to 서버
    • 백엔드 시스템 통신
  • 앱 클라이언트
    • 아이폰, 안드로이드
  • 웹 클라이언트(Ajax)
    • HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용 (AJAX)
    • 예) React, VueJs 같은 웹 클라이언트와 API 통신
  • POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
  • GET: 조회, 쿼리 파라미터로 데이터 전달
  • Content-Type: application/json을 주로 사용 (사실상 표준)
    • TEXT, XML, JSON 등등

5.2. HTTP API 설계 예시

'POST 기반 등록'

• 클라이언트는 등록될 리소스의 URI를 모른다.
  • 회원등록 /members -> POST
  • POST /members
• 서버가 새로 등록된 리소스 URI를 생성해준다.
  • HTTP/1.1 201 Created
    Location: /members/100
  • 예) 회원등록시, 회원번호는 API단에서 생성한다.
         (고객이 가입정보에 회원번호를 입력하지 않는다)
• 컬렉션 (Collection)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리
  • 여기서 컬렉션은 /members

[ 예시 ]

• 회원 목록 /members -> GET
• 회원 등록 /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 /members/{id} -> PATCH, PUT, POST
  • 보통은 PATCH를 사용하는 것을 추천 (수정하려는 데이터만 넘겨서 수정 가능)
  • PUT은 완전히 덮어써도 괜찮은 경우
    • 예) 게시판의 게시글을 수정하는 경우
• 회원 삭제 /members/{id} -> DELETE

'PUT 기반 등록'

• 클라이언트가 리소스 URI를 알고 있어야 한다.
  • 파일 등록 /files/{filename} -> PUT
  • PUT /files/start.jpg
  • 예) 파일 등록 (클라이언트가 파일명을 알고있다)
• 클라이언트가 직접 리소스의 URI를 지정한다.
• 스토어 (Store)
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 여기서 스토어는 /files
  • 예) 정적 컨텐츠 관리, 원격 파일 관리

[ 예시 ]

• 파일 목록 /files-> GET
• 파일 조회 /files/{filename} -> GET
• 파일 등록 /files/{filename} -> PUT
• 파일 삭제 /files/{filename} -> DELETE
• 파일 대량 등록 /files -> POST
  •  

'HTML FORM 사용'

• 순수 HTML + HTML form 사용
• HTML FORM은 GET, POST만 지원
• 컨트롤러(controller), 컨트롤 URI
  • GET, POST만 지원하므로 제약이 있음
  • 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
  • POST의 /new, /edit, /delete가 컨트롤 URI
  • HTTP 메서드로 해결하기 애매한 경우 사용 (HTTP API 포함)
    

[ 예시 ]

• 회원 목록 /members -> GET
• 회원 등록 폼 /members/new -> GET
• 회원 등록 /members/new, /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 폼 /members/{id}/edit -> GET
• 회원 수정 /members/{id}/edit, /members/{id} -> POST
• 회원 삭제 /members/{id}/delete -> POST

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

https://restfulapi.net/resource-naming/

4. HTTP 메서드

4.1. HTTP API를 만들어보자

'회원 정보 관리 API의 URI를 설계해보자'

• 회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 / create-member
• 회원 수정 /update-member
• 회원 삭제 /delete-member
  
  
  

'이것은 좋은 URI 설계일까?'

• URI 설계시 가장 중요한 것은 리소스 식별이다
• 리소스의 의미는 뭘까?
  • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다!
  • 예) 미네랄을 캐라 -> 미네랄이 리소스
  • 회원이라는 개념 자체가 바로 리소스다.
• 리소스는 어떻게 식별하는게 좋을까?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
• URI 계층 구조를 활용한다.
  • 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
  • 예) http://test.example.com/members/{id}

'리소스 식별, URI 계층 구조를 활용하여 URI 설계를 다시 해보자!'

• 회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}
  
• 참고: 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장(member -> members)
  
  
  
  

'같은 리소스를 사용하는 경우, 어떻게 구분해야 할까?'

• 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • 리소스: 회원
  • 행위: 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사 (미네랄을 캐라)
• 행위(메서드)는 HTTP 메서드로 구분한다.

[ HTTP 메서드 ]

• GET: 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
• POST: 요청 데이터 처리, 주로 등록에 사용
  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 애매한 곳은 POST를 사용하면 된다 (다른 메서드로 처리하기 애매한 경우)
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • POST와 차이점: 클라이언트가 리소스 위치를 알고 URI 지정
    • 예) /members/{id}
  • PUT은 기존 리소스를 삭제하고 완전히 대체하기 때문에 중요한 데이터는 PUT을 사용하면 안된다.
    (중요한 데이터를 부분 수정하려면 PATCH를 사용한다)
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
  
  

[ HTTP 메서드 속성 ]

• 안전 (Safe Methods)
  • 호출해도 리소스를 변경하지 않는다.
  • GET, HEAD 메서드가 안전 메서드이다.
• 멱등 (Idenmpotent Methods)
  • 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다. (외부 요인으로 중간에 리소스가 변경되는 것은 고려 X)
  • 멱등 메서드
    • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
    • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
    • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
    • POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
      
    • PATCH: 멱등으로 설계할 수도 있지만, 멱등이 아니게 설계할 수도 있다. (참고)
      
  • 활용
    • 자동 복구 메커니즘
    • 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거
      
• 캐시가능 (Cacheable Methods)
  
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 메서드가 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용
    • POST, PATCH는 본문 내용까지 캐시 키로 교려해야 하는데, 구현이 쉽지 않음
      
      

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

3. HTTP 기본

3.1. 모든 것이 HTTP

'HTTP 메시지에 모든 것을 전송'

• HTML, TEXT
• IMAGE, 음성, 영상, 파일 등
• JSON, XML
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• HTTP/1.1이 현재 가장 많이 사용하는 버전이며, 그 이후 버전은 성능 개선 위주

[ 기반 프로토콜 ]

• TCP : HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용 (HTTP/2, HTTP/3 도 점점 증가)

[ HTTP 특징 ]

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이트리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능
  
  

3.2. 클라이언트 서버 구조

'Request Response 구조'

• Request Response 구조 (클라이언트와 서버를 개념적으로 분리)
• 클라이언트는 UI와 사용성, 서버는 복잡한 비지니스 로직 및 데이터를 전담 (역할 분리 > 독립적 진화 가능)
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

3.3. Stateful, Stateless

'HTTP는 무상태 프로토콜을 지향한다 (Stateless)'

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 장점: 서버 확장성 높음 (스케일 아웃 > 수평 확장 유리)
• 단점: 클라이언트가 추가 데이터 전송 (필요한 데이터를 모두 넘겨야 하기 때문)
• 실무 한계
  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
    • 상태 유지: 로그인이 필요한 화면
      • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
      • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지 (무상태에서 로그인 상태 유지하는 방법)
      • 상태 유지는 최소한만 사용
    • 무상태: 로그인이 필요 없는 단순한 서비스 소개 화면
• 결론: 애플리케이션 설계시에는 최대한 무상태로 설계하고, 상태 유지는 최소한만 사용한다.

[ Stateful, Stateless ]

• 상태 유지: 중간에 다른 서버로 바뀌면 안된다.
                  (다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.)
  • 중간에 서버가 장애나면? 클라이언트는 처음부터 다시 요청을 해야한다.
    
    
• 무상태: 클라이언트의 상태를 보존하지 않으므로, 중간에 다른 서버로 응답할 수 있다.
  
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
  • 중간에 서버1이 장애나면? 서버2가 응답하면 된다.
    
    

3.4. 비 연결성 (connectionless)

'비 연결성이란?'

• 연결을 유지하지 않는 모델이다.
• HTTP는 일반적으로 초 단위의 이하의 빠른 속도로 응답 (요청할 때마다 연결하여 사용 가능, 요청이 끝난 후에는 연결 종료)
• 1시간 동안 수천명이 서비를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
  • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버의 자원을 매우 효율적으로 사용할 수 있다. (최소한의 자원 사용하여 서버 유지 가능)
• 한계와 극복
  • TCP/IP 연결을 새로 맺어야 함 (3 way handshake 시간 추가)
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS,CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
    (연결만 상태 유지하여, 매 요청시 연결을 새로 하지 않도록)
  • HTTP/2, HTTP/3에서 더 많은 최적화
• 대용량 트래픽 설계시에는 Stateless를 꼭 기억하자
  • 같은 시간에 발생하는 대용량 트래픽
  • 이벤트가 생길때 사용자가 급증하는 경우
  • 팁: 정적 페이지를 하나 보게 한 다음, 이벤트 페이지로 들어가게 만드는 방법 (최대한 동시 요청을 적게)
    
    

3.5. HTTP 메시지

'HTTP 메시지 구조'

[ 예시 ]

• 요청 메시지

• 응답 메시지

3.6. HTTP 정리

'지금은 HTTP 시대'

• HTTP 메시지에 모든 것을 전송
• HTTP 역사 HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스)
• HTTP 메시지
• 단순함, 확장 가능
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술 (HTTP 메시지도 매우 단순)
  
  

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

Spring Boot 세팅을 위해, 요즘 제일 많이 사용하는 IDEA인 인텔리제이를 설치해보려고 한다.

버전은 무료버전인 Community 버전을 설치해볼 생각이다.

1. IntelliJ

'IntelliJ 란?'

•  IntelliJ IDEA는 JetBrains사에서 제작한 상용 자바 통합 개발 환경
•  IntelliJ 혹은 IDEA로도 불린다.

2. 설치하기

2.1. 젯브레인 사이트 접속

• https://www.jetbrains.com/idea/
• 우측 상단에 Download 버튼 클릭

2.2. Community Edition 버전 다운로드

• Community Edition 버전은 무료이지만 제한적인 기능을 제한하고 있다.
• Ultimate 버전은 유료버전으로 완전한 기능을 제공한다. (30일 무료체험 가능)
• Download 클릭하여 .exe 파일 설치 (무설치용은 .zip 파일을 선택 후 다운로드)

2.3. 설치

• Create Desktop Shortcut: 바로가기 생성 여부
• Update PATH variable(restart needed) : 윈도우 환경변수에 자동으로 추가 할 수 있도록 체크
• Update Context menu : 프로젝트로 폴더 열기
• Create Association : 본인이 사용할 환경 선택

2.4. 실행

2.4. 정리

• 스터디 용도로는 Community 버전도 적당한 기능을 제공한다고 생각한다.
• 프로젝트 실행시, 확실히 이클립스 비해 가볍고 빠른거 같다.
• 무료버전을 사용하다가, 불편함이 느껴지면 유료버전으로 넘어갈 생각이다.
  (얼티밋 에디션은 개인용 버전이 월간 14.9달러, 연간 149달러에 판매되고 있다.)
• 다음 포스팅에서는, 설치한 인텔리제이에 Spring Boot 프로젝트 생성을 해볼 생각이다.

References

https://goddaehee.tistory.com/195

2. URI와 웹 브라우저 요청 흐름

2.1. URL (Uniform Resource Identifier)

'URI? URL? URN?'

• URI와 URL이 혼동되기 쉽다. 결론부터 말하자면 URI는 URL와 URN의 상위 개념이다.

[ URI 단어 뜻 ]

• Uniform: 리소스 식별하는 통일된 방식
• Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier: 다른 항목과 구분하는데 필요한 정보

[ URL, URN ]

• URL - Locator: 리소스가 있는 위치를 지정
• URN - Name: 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• 통상적으로 URI와 URL을 같은 의미로 사용하기도 한다.

[ URL 문법 ]

https://www.google.com:443/search?q=hello&hl=ko 

• 프로토콜 (https)
• 호스트명 (www.google.com)
• 포트 번호 (443, 생략가능)
• 패스 (/search)
• 쿼리 파라미터 (q=hello&hl=ko)

2.2. 웹 브라우저 요청 흐름

'브라우저에 검색창에 'www.google.com'을 입력하면 일어나는일'

1.  'www.google.com'에 대한 DNS 서버를 조회
   • IP와 PORT 정보를 얻는다
   • 캐싱된 DNS 기록을 체크
2.  웹 브라우저가 HTTP 요청 메시지를 생성
3.  SOKET 라이브러리를 통해 OS 단으로 HTTP 메시지를 전달한다.
   • TCP/IP 연결 (구글 서버와 연결 상태 확인)
   • 데이터 전달 (OS 단으로)
4.  TCP/IP 패킷 생성, HTTP 메시지 포함
5.  웹 브라우저에서 요청 패킷을 구글 서버에 전달 / 도착
6.  구글 서버에서 HTTP 요청 메시지에 대한 HTTP 응답 메시지 생성
7.  구글 서버에서 응답 패킷을 웹 브라우저에 전달 / 도착
8.  받은 응답 패킷을 기준으로 웹 브라우저에 HTML 렌더링

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

실무에서 백엔드 개발을 진행하면서, 네트워크/인프라 등 배경지식이 부족하다고 느껴져서

네트워크 기초에 대한 부분을 공부하기로 하였다.

실무 개발에 필요한 HTTP의 전체 흐름 이해하기 위한 포스팅이며

'모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 학습한 내용을 정리할 생각이다.

1.인터넷 네트워크

1.1. 인터넷 통신

'인터넷 상에서 컴퓨터 둘은 어떻게 통신할까?'

•  직접 연결 (클라이언트와 서버, 둘 사이가 가까운 경우), 하지만 한계가 있다. 사내망 같은 사설망에서만 사용
•  인터넷망 이용(거리가 멀어도 통신 가능)하며, 인터넷망은 IP를 사용하여 통신한다.

1.2. IP(인터넷 프로토콜)

'복잡한 인터넷망은 어떻게 통신을 할까?'

•  클라이언트와 서버에 IP 주소를 부여 (출발지와 목적지에 대한 주소)
•  IP 주소에 데이터 전달
•  패킷이라는 통신 단위로 데이터 전달

[ IP ]

•  인터넷 프로토콜 (Internet Protocol)의 약자
•  네트워크상에서 컴퓨터(노드)를 식별하기 위한 위치 주소
•  한계 및 문제점
  • 비연결성: 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷 전송
  • 비신뢰성: 중간에 패킷이 오거나, 순서대로 안 오는 경우 신뢰할 수 없다.
  • 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 2개 이상인 경우 구별 불가
• 해당 한계들을 극복하고자, TCP/UDP가 등장하기 시작했다.

[ IP 패킷 ]

• 정보 : 출발지 IP, 목적지 IP, 기타
• 출발지 IP에서 목적지 IP로 요청을 클라이언트 패킷에 담아 전달한다.
• 목적지 IP에서 요청에 대한 응답을 서버 패킷에 담아 전달한다.

1.3. TCP/UDP

'IP만으로 통신할 때의 한계나 문제점을 어떻게 해결해야 할까?'

• 비연결성 : 통신 전에 클라이언트와 서버의 연결 상태 및 데이터 전달 보증 확인
• 비신뢰성 : 패킷에 데이터의 순서 정보를 함께 보낸다
• 프로그램 구분 : 프로그램별 구분 값(PORT)을 이용

[ 인터넷 프로토콜 스택의 4계층 ]

• 애플리케이션 계층 - HTTP, FTP
• 전송계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층

[ TCP (Transmission Control Protocl) 특징 ]

• 연결지향 - TCP 3 way handshake (가상 연결, 논리적 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

[ TCP 3 way handshake ]

1. SYN : 클라이언트 > 서버 (접속 요청)
2. SYN+ACK : 서버 > 클라이언트 (연결 요청 수락)
3. ACK: 클라이언트 > 서버 (연결 요청 수락에 대한 응답)
4. 데이터 전송 (참고: 요즘에는 최적화로 인해 ACK와 함께 데이터 전송도 가능)

[ UDP (User Datagram Protocol) ]

• 연결지향 X
• 데이터 전달 보증 X
• 순서 보장 X
• IP와 거의 같다. +PORT +체크섬 정도만 추가
• 애플리케이션에서 추가 작업 필요

UDP는 왜 쓰는걸까?

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• TCP에 비해 보안적으로 덜 안전하지만, 많은 양의 데이터를 빠르게 전달 가능 (영상 스트리밍이나 음성에 활용)
• 최근 인터넷이 거의 TCP 기반으로 되어있기 때문에, TCP를 수정하기가 어려움 
• 그래서 최적화를 위한 수정 개발시에는 UDP를 활용, 최근에는 UDP가 뜨고 있다고함 (ex: HTTP 프로토콜)

1.4. PORT

'한 번에 둘 이상 연결해야 한다면 어떻게 해야할까?'

[ PORT 특징 ]

• 같은 IP 내에서 프로그램(프로세스)를 구분
• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

1.5. DNS

'IP는 기억하기 어렵고, 변경될 수 있다.'

•  도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환
  
  

References

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC