[NBCAMP | Spring 6기] 78일차 TIL + HTTP, HTTPS

👈  이전글

[NBCAMP | Spring 6기] 74일차 TIL + 2차 모의 면접

---

KDT 실무형 스프링 백엔드 엔지니어 양성과정 6기

 

🗝 오늘의 학습 키워드 :  HTTP HTTPS

📖 공부한 내용 본인의 언어로 정리하기

[내일배움캠프 - 주특기 플러스 심화 주차 개인 과제] 트러블 슈팅

 

 

 

---

⌛ 오늘의 회고

오늘 개인 과제 제출, 스터디 발표, 국민 취업 지원제도 상담이 모두 겹쳐서
오전 시간이 엄청나게 바쁘게 흘러갔다.
다행히 스터디 발표도 잘하고 과제 제출도 그런대로 잘하고 지각하긴 했지만 국취제 상담도 무사히 마칠 수 있었다.
사실 스터디 발표는 HTTP와 HTTPS의 내용이 이정도로 많을 줄 몰랐는데
모르는 부분을 파고 파고 또 파다보니 양이 너무 많아져
10분짜리 발표를 해야하는데 30분짜리 PPT를 만들고 말았다.
PPT가 아까워서 녹화는 30분짜리로 하고
발표는 PPT를 조금 줄여서 했다.
그런데 국취제 때문에 아침 지옥철을 타고 국취제 상담 장소 근처의 카페에서 발표를 했는데
발표 시간에 너무 딱 맞게 카페에 도착한데다
노트북 켜는데 시간이 조금 소모되어 그만 스터디 시간에 늦고 말았다.
(팀원 분들 정말 죄송해요 ㅜㅜ)
다행히 양해를 해 주셔서 무사히 발표를 하고
과제 제출을 했는데
알고보니 과제 제출 링크만 공유하면 되는 것이 아니라
README 파일과 트러블슈팅 TIL도 작성해야하는 것이었다.
이미 상담에 늦어서 11시 상담을 10분 정도 양해를 구했는데
그것보다 20분 늦게 도착해버렸다.
그것도 미리 구체적으로 작성해 둔 Commit 메세지가 아니었더라면 불가능했을 것이다.
README랑 TIL이랑 그냥 거의 똑같게 복.붙하고 상담 장소로 뛰어갔다.
다행히 상담사 선생님께서 크게 뭐라고 하시진 않았지만 20분이 짧은 시간이 아닌데 기다리게 해서 정말 죄송했다.
정말 시간 약속 다시는 어기는 일이 없도록 해야겠다.
취업할 분야나 장소 등에 대해 생각해 둔 것 없는지 이야기 나누고
다시 지하철을 타고 왔다.
처음에 서울에 올라왔을 때, 지하철이 마냥 좋았는데
계속 타다보니 거리가 멀면 멀미 때문에 졸음을 참기 힘들었는데
오늘 아침에는 발표 때문에 열심히 발표 대본을 중얼거리고 온 덕분에 안 졸고 쌩쌩하게 지하철을 잘 타고 왔던 것 같다.
앞으로 출근하면 지하철 탈 일이 많을텐데 그럴 때마다 공부하면서 멀미도 견디고
틈새 공부도 해야겠다고 생각했다.
저녁에는 급히 제출했던 트러블슈팅 부분에 회고 부분 추가하고
QueryDSL문제를 풀어보았다.
생각만큼 쉽게 풀리진 않았지만 QueryDSL로 쿼리를 작성하면 IDE로 편하게 작성할 수 있고
가독성이 좋아서 그런지 재미있게 뒤에 문제를 풀었다.
과제 피드백도 보았는데 문제에는 if문을 써도 된다고 했는데
실제로는 if문으로 조회 조건을 분리하여 쿼리 메서드를 각각 만드는 것이 좋은 것이 아닌가보다.
조건이 null일 때는 is null을 사용한 것이 정답이었다.
새로운 부분을 또 배운 것 같다.
내일은 스봉클 가는데 너무 기대된다!

 

🗨️ 무엇을 새롭게 알았는지

HTTP

(HyperText Transfer Protocol)

• HTTP란?
  • 1989년 팀 버너스 리에 의해 처음 설계됨
  • WWW(World-Wide-Web) 기반에서 전세계적인 정보를 기여하는 데 큰 기여
  • Hypertext인 HTML을 전송하기 위한 통신 규약
  • 애플리케이션 계층에서 동작하는 프로토콜로 TCP/IP 위에서 동작
  • 80번 포트 사용
•  버전
  • 1.0 : 한번의 Connection으로 1번의 요청과 응답만 가능
  • 1.1
    • Persistent Connection
      • 일정 시간동안 연결하여 여러번의 요청과 응답 가능
      • 요청에 대한 응답이 와야 다음 요청이 가능하여 대기 시간이 발생하는 문제
    • Pipelining
      • 서버에 요청을 담는 큐를 생성하여 한번에 여러 요청을 보내고 순차적으로 응답을 받는 방식
      • Persistent Connection의 문제는 해결했으나
        중간에 한 요청이 막히면 뒤의 요청도 대기해야하는 Head of Line Blocking 문제 발생
      • 중복된 헤더를 요청에 계속 넣어야하는 Headers 구조 중복 문제
  • 2
    •  Multiplexing(다중화)
      • HTTP 메세지를 Header 프레임과 Data프레임으로 분리
      • 프레임을 담은 메세지를 스트림으로 전송
      • 바이너리 프레임의 도입으로 순서 상관 없이 병렬적으로 요청 처리 가능
      • 병렬 처리된 메세지 중 하나가 막히면 뒤의 메세지가 대기해야하는 TCP Head of Line Blocking 문제
    • Headers Compression
      • 중복된 헤더는 인덱스만 보내고 새로운 헤더는 Huffman 인코딩을 통해 전송
      • Headers 구조 중복 문제 해결
    • Server Push
      • 클라이언트가 요청하지 않은 리소스이더라도 서버가 필요할 것이라 예측되는 리소스를 알아서 push
      • 클라이언트는 서버가 push한 리소스에 대해서는 따로 요청을 하지 않아도 되므로
        보내야할 요청의 수가 줄어듬.
    • Stream Prioritization
  • 3
    • Quic : 전송 계층 프로토콜
    • TLS 암호화를 통해 IP 스푸핑, Reply Attack 방지 >> 보안성 향상
    • 독립된 스트림으로 TCP Head of Line Blocking 해결 , 향상된 Multiplexing 제공
• Connection
  • keep-alive
  • close
• 데이터를 평문으로 보내기 때문에 보안에 취약
• 특히 비밀번호, 주민등록번호와 같은 민감 정보 전송 시, 제3자에게 데이터가 그대로 노출되어 패킷 스니핑, 데이터 위변조에 그대로 노출될 수 있음

HTTP에 보안 요소인 TLS/SSL 암호화를 추가한 HTTPS가 탄생하게 됨

 

HTTPS

• HTTP에 TLS/SSL 암호화가 추가된 방식
• 443 포트 사용
• 기능
  • 클라이언트가 서버에게 보내는 데이터를 제3자가 보지 못하게 함.
    • 패킷 스니핑, 데이터 위/변조 방지
  • 클라이언트와 서버가 믿을 수 있는지 검증
    • 인증서를 통한 서버 검증
    • 피싱 방지
• TLS/SSL hand-shake
  • 대칭키 암호화와 비대칭키 암호화 사용
  • 속도와 안정성을 모두 확보
  • 서버 공개키는 비대칭키 암호화를 통해 주고 받고
  • 서버 공개키로 클라이언트의 세션키를 암호화하여 서버에 전송
  • 제3자는 비대칭키 암호화된 세션키를 스니핑하거나 위/변조 불가
  • 안전하게 세션키를 공유
  • 세션키를 대칭키로 데이터를 암호화 및 복호화

💭 내일 학습할 것은 무엇인지

• 팀 프로젝트 시작
• 면접 스터디 준비

---

👉  다음글