1. 아이템 선정

전반적인 웹의 기본 소양이 되는 CRUD 게시판을 만들고, 기능을 하나씩 추가해 나가는 식으로 진행한다.


2. 개요

  • 프로젝트 명칭 : 대전의 문화 게시판 사이트
  • 개발 인원 : 1명
  • 개발 기간 : 2023.4.14 ~ 2022.05.12
  • 주요 기능 :
    • 게시판 - CRUD 기능, 조회수, 페이징 및 검색 처리
    • 사용자 - Security 회원가입 및 로그인, OAuth 2.0 구글, 네이버 로그인, 회원 정보 수정, 유효성 검사 및 중복 검사
    • 댓글 - CRUD 기능 
  • 개발 언어 : Java 15
  • 개발 환경 : SpringBoot 2.7.3, Maven, jpa(Spring Data JPA), Javascript,html,css
  • 데이터베이스 : MySQL
  • 형상관리 툴 : GitHub
  • 간단 소개 : 전반적인 웹의 기본 소양이 되는 게시판,대전의 소개

3. 요구사항 분석

1. 회원 가입 페이지

  • 유효성 검사
    • 닉네임은 최소 3글자 이상이며 중복 불가,ajax를 이용한 실시간 처리
    • 이메일 형식 패턴 적용해 확인
    • 형식이 다르거나 중복,오류일 경우, 중복코드와 메세지 보여주기
    • 비밀번호는 브라우저에는 텍스트로 등록되나 DB에는 sha-256알고리즘으로 변형
  • 중복확인
    • 데이터베이스에 존재하는 아이디를 입력한 채 회원가입 버튼을 누른 경우 "이미 사용중인 아이디입니다."의 메시지를 보여주기
    • 모든 검사가 통과되었다면 로그인 페이지로 이동시키기

2. 로그인 페이지

  • 로그인을 하지 않은 경우 아래 페이지만 이용가능
    • 회원가입 페이지
    • 로그인 페이지
    • 게시글 목록 조회 페이지
    • 게시글 상세보기 페이지
    • 게시글 검색 페이지
    • 그 외 로그인을 하지 않거나 올바르지 않은 경로로 접속한 사용자가 로그인이 필요한 경로에 접속한 경우 로그인 페이지로 이동
  • 로그인 검사
    • 아이디와 비밀번호가 일치하지 않을 시 "아이디 또는 비밀번호가 일치하지 않습니다. "의 메시지를 보여주기
    • 이외의 다른 에러 메시지 또한 처리하기
    • 모든 검사가 통과되었다면 로그인 후 이전에 있던 페이지로 이동시키기

3. 회원정보 수정

  • 회원정보 수정은 아이디를 제외한 모든 정보 수어가능
  • 닉네임이 중복확인을 통해 중복일 경우 “이미 사용중인 닉네임입니다.” 메시지 보여주기
  • 닉네임은 최소 3자 이상을 입력해야 하며 ajax를 이용한 실시간 처리
  • 비밀번호 수정 또한 텍스트로 입력되지만 DB에는 sha-256알고리즘으로 인한 보안강화
  • 수정 완료 시 수정 날짜 업데이트해주기

4. 비밀번호 찾기 임시 패스워드 메일로 발송 시스템

  • 패스워드를 잊었을 때 등록해놓은 이메일로 임시 비밀번호가 발송
  • 데이터베이스에 존재하는 이메일로 임시 비밀번호가 발송된다
  • 임시 비밀번호로 로그인 한 뒤 수정으로 비밀번호를 바꿀 수 있도록 구현

5. 게시글 검사

  • 게시글 작성, 수정 시 제목과 내용은 공백 혹은 빈칸으로 작성하지 않도록 하기
  • 게시글 작성, 수정 시 카테고리 선택을 해야함
  • 게시글 상세보기시 조회수가 증가한다
  • 게시글에는 좋아요 또는 싫어요로 리액션이 가능하며 중복선택 불가
  • 내가 작성한 글만 수정, 삭제 가능하게 하기
  • 로그인을 하지 않고 글 작성 버튼을 누른 경우 로그인 페이지로 이동,로그인하면 다시 글작성 페이지로 돌아오도록 구현

6. 댓글 검사

  • 댓글은 로그인한 사용자만 작성 가능하게 하기
  • 댓글 작성 및 수정시 빈칸 혹은 공백으로 된 경우  오류코드와 메시지 보여주기
  • 댓글 수정 및 삭제는 해당 댓글 작성자만 가능하게 하기
  • 게시글 삭제 시 해당 댓글 데이터도 같이 삭제되게 하기

7. 관리자 페이지

  • 관리자는 코드번호 7,일반회원은 3으로 구분
  • 관리자는 모든 게시글,댓글의 수정,삭제 권한이 있으며 따로 페이지와 데이터가 존재

8. API 구현

  • openweather 사이트에서 공개 api를 가져와 ajax로 실시간 날씨의 정보를 보여주도록 기능 실현
  • kakao developer 사이트에서 제공하는 길찾기 api를 가져와 대전의 맛집을 키워드로 검색하도록 실현

4. DB 설계

5. 프로젝트 진행 과정

 

더보기
1. 테스트데이터 생성
2. 중복제거

3-1. localhost:8081/usr/article/doDelete?id=1
결과 -> 1번글이 삭제되었습니다 or 1번글은 존재하지 않습니다

3-2. localhost:8081/usr/article/doModify?id=1
결과 -> 1번글이 수정되었습니다 + 수정된 게시물 리턴
           or 1번글은 존재하지 않습니다

2023-04-14, 1일차

  •  

2023-04-17, 2일차

 

2023-04-18, 3일차

2023-04-19, 4일차

  •  

2023-04-20, 5일차

2023-04-21, 6일차

TODO

주제 다시 고민 
기능 고민

2023-04-24, 7일차

2023-04-25, 8일차

2023-04-26, 9일차

2023-04-27, 10일차

TODO : 좋아요 싫어요 버튼 고민

2023-04-28, 11일차

TODO : 버튼 눌렀을 때 좋아요, 싫어요 취소 처리

2023-05-02, 12일차

댓글--------------------------------------
회원가입
마이페이지
회원정보 수정

AJAX
API

메일?

관리자

TODO : 댓글이 너무 길다면?

2023-05-03, 13일차

2023-05-04, 14일차

토스트 UI 관련자료

2023-05-08 15

TODO : 회원가입시 ajax 로 아이디 중복체크

2023-05-09 16

2023-05-10 17일차

2023-05-11 18

2023-05-12 19일차

6. 마무리 하며

 

안녕하세요, 저는 최근혁이라고 합니다. 현재 백엔드 개발자 양성과정을 수료했으며 그에 바탕하여 지원서를 제출하게 되었습니다.

저는 어릴 때부터 컴퓨터와 기술에 관심이 많았습니다. 교육 중에는 프로그래밍 언어와 데이터베이스 시스템 등 다양한 IT 기술을 배웠으며, 이를 바탕으로 '대전 게시판 프로젝트'를 수행하였습니다. 

제가 가진 강점 중 하나는 문제 해결 능력입니다. 프로젝트에서는 복잡한 문제를 해결하면서도 정확성과 효율성을 유지하는 것이 중요하다는 것을 배웠습니다. 공공 api를 가져와서 내가 원하는 곳에 실행시키는 것에 어려움을 겪었지만, 포기하지 않고 새로운 방법과 새로운 지식을 공부하여 결국은 결과를 도출해냈습니다.또한, 새로운 기술과 도구를 학습하면서 항상 도전적인 태도로 임하며, 팀원들과의 협업을 통해 문제를 해결하는 것을 즐기는 편입니다.

저는  제 기술과 경험을 활용하여 회사의 성장과 발전에 기여하고 싶습니다. 또한, 회사에서 제공하는 교육 및 훈련을 통해 끊임없이 발전하고 성장하며, 좋은 동료와 함께 일하는 경험을 쌓고 싶습니다.

감사합니다.

 

프로젝트 깃허브:https://github.com/guenhyuck/project2

 

GitHub - guenhyuck/project2

Contribute to guenhyuck/project2 development by creating an account on GitHub.

github.com

공부 기록,성장과정 블로그:https://thecodelab.tistory.com/

 

 

스프링기본동작순서

https://server-engineer.tistory.com/253




JSP와 SPRING의 차이점

문득 궁금해져서 검색해보니 아주 명쾌한 비유와 설명을 찾았다.

JSP란?
JSP는 HTML문서에 내부적으로 자바문법을 사용할 수 있게 하는 웹페이지 스크립트 언어입니다.

Spring Framework 란?
Spring은 다양한 개발 빠르게 적용할 수 있게 만들어 놓은 도구입니다. Java는 삽을 들고 땅을 파는 거라면, Spring은 포크레인으로 땅을 파는 것과 같다고 표현할 수 있습니다.

JSP와 Spring의 차이
JSP는 웹 페이지 영역에서 사용되고, Spring은 웹 서비스 전반적 환경을 구성합니다.

Spring이 나라라고 한다면, JSP는 도시 입니다. 스프링은 프로그램 전반적인 근본이 되는 환경을 구축하고있고, JSP는 그 환경의 일부분에 사용되는 언어입니다.
출처 : https://cloudstudying.kr/questions/79

HttpSession 인터페이스

HttpSession 인터페이스는 둘 이상의 page request에서 사용자를 식별하거나, 웹 사이트를 방문하고 해당 사용자에 대한 정보를 저장하는 방법을 제공한다.

Servlet container는 HttpSession를 사용하여 HTTP client - HTTP server 간의 세션을 생성한다. 이 때, 세션은 한 명의 사용자에 해당한다. 서버는 Cookie, rewriting URL와 같은 방법으로 세션을 유지하면서 관리할 수 있다. 객체를 세션에 바인딩하여 사용자 정보를 유지할 수 있다.

관련 메서드

  • HttpSession's setAttribute("Key", Value)
    • "Key"를 사용하여 객체를 세션에 바인딩한다.
    • Value는 값으로 들어올 자료형을 예측할 수 없기에 Object형으로 업캐스팅하여 모두 받아낸다.
  • HttpSession's getAttribute("Key")
    • "Key"로 바인딩된 객체를 돌려주고, "Key"로 바인딩된 객체가 없다면 null를 돌려준다.
    • Value는 세션을 저장할 때 Object형으로 업캐스팅을 했으므로, 가져올 땐 원래대로 다운캐스팅 해야 한다.
  • HttpServletRequest's getSession(true)
    • 이미 세션이 있다면 그 세션을 돌려주고, 세션이 없으면 새로운 세션을 생성한다.
    • request.getSession()로 쓸 수 있다.
  • HttpServletRequest's getSession(false)
    • 이미 세션이 있다면 그 세션을 돌려주고, 세션이 없으면 null을 돌려준다.

예제 : 로그인,로그아웃 할 때 세션 사용하기

 

 

<로그인시>


HttpSession session = request.getSession();
session.setAttribute("loginedMemberId", memberRow.get("id"));
session.setAttribute("loginedMemberLoginId", memberRow.get("loginId"));

response.getWriter()
.append(String.format("<script>alert('%s님 환영합니다'); location.replace('../article/list');</script>",
memberRow.get("name")));


/////////////////////////////////////////////////////////////////

<로그아웃시>

HttpSession session = request.getSession();
session.removeAttribute("loginedMemberId");
session.removeAttribute("loginedMemberLoginId");

response.getWriter()
.append(String.format("<script>alert('로그아웃 되었습니다'); location.replace('../home/main');</script>"));

로그인 로그아웃 -> HttpSession기능 사용

remove,set,getAttribute 찾아보기

set -> 로그인 시
get -> 로그인 했나?
remove -> 로그아웃할 때 사용

개요

 >  쿠키(Cookie)세션(Session) 각각 특성 및 차이 확실히 분류하기

 

메모

1. 공통점 : 웹 통신간 유지하려는 정보(ex:로그인 정보 등)를 저장하기 위해 사용하는 것(?)

2. 차이점 : 저장위치, 저장형식, 용량제한, 만료시점 등 (해당 포스트 하단에 '표'로 정리됨)
               쿠키 : 개인 PC에 저장됨.
               세션 : 접속중인 웹 서버에 저장됨.

* 위 내용 관련하여 조금 더 자세한 내용은 아래 "내용" 참고하세요~

 

내용

쿠키와 세션을 사용하는 이유

HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용된다.
 1. Connectionless 프로토콜 (비연결지향)
    클라이언트가 서버에 요청(Request)을 했을 때,
    그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식이다.
        - HTTP 1.1 버전에서 연결을 유지하고, 재활용 하는 기능이 Default 로 추가되었다.
          (keep-alive 값으로 변경 가능)

 2. Stateless 프로토콜 (상태정보 유지 안함)
    클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다.
    클라이언트와 첫번째 통신에서 데이터를 주고 받았다 해도,
    두번째 통신에서 이전 데이터를 유지하지 않는다.
  1. But, 실제로는 데이터 유지가 필요한 경우가 많다.
서버와 클라이언트가 통신을 할 때 통신이 연속적으로 이어지지 않고 한 번 통신이 되면 끊어진다.
따라서 서버는 클라이언트가 누구인지 계속 인증을 해줘야 한다. 하지만 그것은 매우 귀찮고 번거로운 일이다.
또한 웹페이지의 로딩을 느리게 만드는 요인이 되기도 한다.그런 번거로움을 해결하는 방법이 바로 쿠키와 세션이다.
정리하면, 클라이언트와 정보 유지를 하기 위해 사용하는 것이 쿠키와 세션이다.



Q. 세션을 쓰면되는데 굳이 쿠키를 사용하는 이유?

A. 세션이 쿠키에 비해 보안도 높은 편이나 쿠키를 사용하는 이유는
세션은 서버에 저장되고, 서버자원을 사용하기 때문에 사용자가 많을 경우 소모되는 자원이 상당하다.
이러한 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여,
서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있다.



쿠키(Cookie)

HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우,
그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.

HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가
필요시 정보를 참조하거나 재사용할 수 있다.


  • 쿠키 특징
    1. 이름, 값, 만료일(저장 기간 설정), 경로 정보로 구성되어 있다.
    2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
    3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
    4. 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.

  • 쿠키의 동작 순서
    1. 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
    2. 웹 서버는 쿠키를 생성한다.
    3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때,
       같이 클라이언트에게 돌려준다.
    4. 넘겨 받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장)
       다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
    5. 동일 사이트 재방문시 클라이언트의 PC에 해당 쿠키가 있는 경우,
       요청 페이지와 함께 쿠키를 전송한다.

  • 사용 예시
    1. 방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력
    2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크


세션(Session)

일정 시간동안 같은 사용자(브라우저)로부터 들어오는
일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.

여기서 일정 시간은 방문자가 웹 브라우저를 통해
웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.


  • 세션 특징
    1. 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
    2. 웹 서버의 저장되는 쿠키(=세션 쿠키)
    3. 브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로,
       쿠키보다 비교적 보안이 좋다.
    4. 저장 데이터에 제한이 없다.(서버 용량이 허용하는 한...)
    5. 각 클라이언트 고유 Session ID를 부여한다.
       Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공

  • 세션의 동작 순서
    1. 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
    2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여,
       클라이언트가 해당 session-id를 보냈는지 확인한다.
    3. session-id가 존재하지 않는다면,
       서버는 session-id를 생성해 클라이언트에게 돌려준다.
    4. 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다.
       쿠키 이름 : JSESSIONID
    5. 클라이언트는 재접속 시,
       이 쿠키(JSESSIONID)를 이용하여 session-id 값을 서버에 전달

  • 사용 예시
    화면이 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지


쿠키와 세션 차이


출처:https://hahahoho5915.tistory.com/32

 

11단계

flex-direction:column;
justify-content:end;

 

 

12단계

flex-direction: column-reverse;
justify-content: space-between;

 

13단계

flex-direction:row-reverse;
justify-content:center;
align-items: end;

 

14단계

order:1;

 

 

 

15단계

order:-3;

 

 

16단계

align-self:end;

 

17단계

 

order : 2;
align-self : end;

 

 

 

18단계

flex-wrap:wrap;

 

 

 

19단계

flex-direction:column;
flex-wrap :wrap;

 

 

20단계

flex-flow : column wrap;

 

21단계

align-content:start;

 

 

22단계

align-content:end;

 

 

23단계

flex-direction:column-reverse;
align-content:center;

 

 

24단계

flex-direction: column-reverse;
flex-wrap: wrap-reverse;
justify-content: center;
align-content: space-between;

난이도 급발진 24단계

1단계

justify-content:flex-end;

 

 

2단계

justify-content: center;

 

3단계

justify-content : space-around;

 

4단계

justify-content:space-between;

 

5단계

align-items:end;

6단계

align-items: center;
justify-content: center;

 

7단계

justify-content:space-around;
align-items:end;

 

8단계

flex-direction:row-reverse;

 

 

9단계

flex-direction:column;

10단계

flex-direction: row-reverse;
justify-content: flex-end;

만약 테이블에 한글 데이터가 저장이 안된다면

  • 1회성 방법
    • 왼쪽 객체브라우저에서 내 DB 찾기. 안보이면 root@localhost 우클릭 후 객체 브라우저 새로고침 클릭
    • 내 DB(실습에서는 board라고 만듦) 우클릭 -> 데이터베이스 변경 선택 -> 아래와 같이 수정
      • 데이터 베이스 문 : utf8mb4
      • 데이터 베이스 대 : utf8mb4_general_ci
    • 변경 버튼 클릭
    •  
     

  • 영구적인 방법
    • 윈도우키 누르고 my.ini 실행
    • 아래 내용으로 바꾸고 저장
        [mysqld]
        datadir=C:/Program Files/MariaDB 10.11/data
        port=3306
        innodb_buffer_pool_size=2026M
        character-set-server=utf8mb4
        [client]
        port=3306
        plugin-dir=C:\Program Files\MariaDB 10.11/lib/plugin
    
    • 윈도우키 누르고 서비스 실행
    • 서비스 목록 중 MariaDB 찾아서 우클릭 - 다시시작 클릭
    • sqlyog 재시작

'DB' 카테고리의 다른 글

DBMS,Spring 3월 24일 6회차  (0) 2023.03.30
DBMS,Spring 3월 23일 5회차  (0) 2023.03.30
DBMS,Spring 3월 22일 4회차  (0) 2023.03.30
DBMS,Spring 3월 21일 3회차  (0) 2023.03.30
DBMS,Spring 3월 17일 2회차  (0) 2023.03.30

HTML / JSP 문서 자체에서 한글 깨짐

해결 방법

<head> 부분에 <meta charset="UTF-8"> 를 추가해준다.

get 방식의 표현에서 한글 깨짐

URL 한글 깨짐

search 값이 깨져서 한글이 보이지 않은다.

이럴 경우 request.getParameter("search")를 할경우 당연히 원하는 결과가 나오지 않는다.

해결 방법

main_shop.jsp 맨위에

euc-kr

이 부분을

utf-8

 

이렇게 바꾸도록 하자

(아래는 복붙용)

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>

또는

server.xml

servers의 sever.xml 에서

Connector

이부분에 URIEncoding="euc-kr" 를 추가하자.

결과

URL 한글 정상 표기

한글이 안깨지므로 당연히 request.getParameter를 사용해도 정상적으로 한글을 가져온다.

Post 방식의 표현에서 한글 깨짐

해결 방법

request.getParameter로 한글이 깨질 경우, 그 전에

request.setCharacterEncoding("utf-8"); 를 먼저 사용 후

가져오면 한글을 정상적으로 가져올 것이다.

ex)

request.setCharacterEncoding("utf-8");

request.getParameter("pigg");

JSP / JAVA 에서 쿼리를 실행 시 한글 깨짐

분명 데이터베이스 상에서는 결과값이 잘 나오는데 JSP / JAVA 에서 쿼리를 실행 시, 결과가 나오지 않은다.

이런 경우 JSP와 DB 사이에서 한글이 깨진 후 쿼리문이 실행되기 때문인데 따로 설정을 해줘야 한다.

해결 방법

server -> context.xml

<Resource name="jdbc/smartdb" auth="Container" type="javax.sql.DataSource"

maxTotal="100" maxIdle="30" maxWaitMillis="10000"

username="root" password="1234" driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost:3306/smartdb?characterEncoding=euckr"/>

맨 밑줄 url 부분에 smartdb(데이터베이스 이름) 뒤에

?characterEncoding=euckr 를 그대로 넣는다.

 

 

출처:https://m.blog.naver.com/alcmskfl17/221913121686

URL은 웹을 뒷받치는 주소체계다.

웹은 수 많은 파일이 연결되어 있는 공간이다. 따라서, 웹에 존재하는 파일을 다른 파일과 구별하는 효과적인 식별자가 필요하다. 웹에서는 파일을 자원 또는 리소스(resource)라고 부르는데 방대한 웹에서 이 자원을 구별하는 식별자가 바로 URL이다. 즉, URL은 웹에서 접근가능한 자원의 주소를 일관되게 표현하는 형식이다.

조금 어려워보이지만 우리가 매일 사용하는 웹은 URL로 구성되어 있다. 웹에서 신문을 읽거나 검색을 하거나 트위터를 사용할 때 모르는 사이에 URL로 만들어진 주소체계를 이용하고 있는 것이다.

URL의 구성

한우에도 부위마다 이름이 있는 것처럼 URL을 구성하는 부분에도 명칭이 있고 각자의 역할이 있다. URL의 구성품도 어느 하나 버릴것이 없다.

  • 프로토콜: URL은 자원을 접근하는 방법인 스킴scheme으로 시작한다. 스킴보다는 프로토콜이라고 부르는게 일반적이므로 앞으로는 프로토콜이라고 쓰겠다.
  • 사용자정보: 사용자 아이디와 비밀번호를 사용자정보userinfo로 부른다. 잘 사용하지 않기 때문에 따로 설명하지 않겠다. (예: https://username:password@www.example.com/)
  • 호스트: 그리고 호스트 주소가 나온다. IP 또는 www.example.com과 같은 도메인명을 쓴다. 호스트명:포트번호 형태로 포트번호를 쓸 수 있는데 선택사항이다.
  • 경로: 호스트 주소 다음에 /으로 시작하는 경로가 나온다. 윈도우의 디렉토리나 폴더와 비슷하다고 보면 된다. 루트 디렉토리가 /으로 시작하는 것이 윈도우와 다르다 (예: https://www.example.com/).
  • 매개변수: 그 다음은 웹서버에 보내는 추가 매개변수(Query 또는 Parameters)가 온다.
  • 부분식별자: 마지막으로 #으로 시작하는 부분 식별자(fragment identifier)가 온다.

프로토콜

프로토콜은 웹에서 서버와 클라이언트간에 어떤 방법으로 자원을 접근할지 알려준다. 웹브라우저에서 가장 많이 사용되는 https/http외에도 mailto: (이메일 주소를 지정하는 프로토콜), ftp: (파일을 주고받는 프로토콜) 등 다양한 프로토콜이 존재한다.

우리가 가장 많이 사용하는 HTTP는 Hyper Text Transfer Protocol이라는 어려운 이름의 약자인데 쉽게 설명하면 웹브라우저와 웹서버 사이에서 웹 문서와 그것을 구성하는 자원을 전송하기 위한 프로토콜이다. 요즘은 HTTPS를 기본 프로토콜로 쓰는데, (https를 지원하지 않는 웹사이트는 여전히 http를 쓴다) HTTP에 보안이 강화된 버전이다.

호스트

URL에서 웹서버의 위치를 지정한다. 도메인 이름(예: www.example.com)이나 IP 주소(예: 127.0.0.1)를 사용할 수 있다.

도메인 이름 뒤에 오는 :80는 포트번호다. 웹서버에서 자원을 접근하기 위해 사용하는 관문(gate)을 가리키는데, 표준 HTTP 포트는 80번 HTTPS는 443이다. 표준 포트를 사용한다면 포트번호는 보통 생략한다.

경로

웹서버에서 자원에 대한 경로다. 실제 물리적 경로가 아니고 웹서버에서 추상화한 경로다(물론 웹서버 설정에서 물리적 경로를 추상화 경로로 사용할 수 있다).

루트 자원을 나타내려면 “/”을 사용한다. 예) https://www.example.com/

루트의 robots.txt를 지정한다면 다음과 같다. 예) https://www.example.com/robots.txt

본 문서의 후반부에서 자세히 설명하겠지만 URL은 ASCII 문자세트에 포함된 문자만 허용한다. 뿐만 아니라, ASCII 문자세트에서도 허용되지 않는 문자가 있다. 이 경우 “%”로 시작하는 16진수로 문자코드를 넣는다. 여러 문자가 있지만 공백(space) 문자를 주목할 필요가 있다. 공백 문자는 그냥 쓰면 안되고 플러스 문자(+)나 “%20”로 치환해야 한다.

예)
https://www.example.com/hello world.html (X)
https://www.example.com/hello+world.html (O)

매개변수 (Query 또는 Parameters)

웹서버에 보내는 추가 파라메터다. 파라메터 하나는 키와 값으로 짝을 이룬다. 파라메터가 여러개면 &문자로 구분한다. 키와 값은 =문자로 구분한다. 웹서버에서 어떤 파라메터를 실제로 지원하는지는 웹서버마다 다르다. 웹서버는 지원하지 않는 파라메터는 무시한다.

부분 식별자 (Fragment identifier)

URL이 지정하는 자원의 세부 부분을 지정할때 쓴다. 부분 식별자가 없어도 그 앞에 오는 URL만으로도 웹의 어떤 자원을 정확히 지정할 수 있다. 부분 식별자는 자원 안에서 어떤 부분을 가르키는 역할을 한다. 부분 식별자가 쓰이는 대표적인 사례는 위키피디어 백과사전이다. 부분 식별자를 세부항목에 대한 책갈피bookmark로 쓸 수 있어서 어떤 글에서 특정 항목으로 바로 이동할 수 있다.

예) https://ko.wikipedia.org/wiki/대한민국#문화 : 위키피디어 “대한민국” 문서에서 “문화” 세부주제로 바로 갈 수 있다.

참, URL에는 ASCII 문자외에는 쓸 수 없다고 했는데 어떻게 한글이 쓰였을까? 자연스럽게 다국어 지원에 대한 이야기로 넘어가자.

다국어 지원

URL에 ASCII 문자 집합외에도 유니코드에서 지원하는 모든 문자를 사용할 수 있다. 물론 조금 복잡해지는 것만 참으면.

도메인 이름과 경로 등에서 다국어를 쓰는 법이 다른데. 도메인 이름에서는 퓨니코드라고 부르는 인코딩 방법으로 만들어진 코드를 “xn--” 문자 뒤에 붙여서 쓴다. 예를 들어, “wiki백과.com”은 “xn--wiki-ei4p334e.com”이 된다.

경로 등에서는 % 다음에 Unicode 코드포인트를 쓴다. 예를 들어, https://ko.wikipedia.org/wiki/대한민국 의 실제 주소는 다음과 같다.
https://ko.wikipedia.org/wiki/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD

“EB 8C 80”의 UTF-8 3 byte로 된 “대”라는 문자의 코드다. 각 바이트의 16진수에 %을 붙여서 %EB%8C%80이 된 것이다.

그런데 크롬같은 웹브라우저에서는 %로 시작하는 복잡한 코드를 보여주지 않고 사용자가 읽기 쉬운 “대한민국”이라고 표시된다. 이것은 웹브라우저가 사용자에게는 읽기 쉬운 글자로 보여주고 내부적으로는 인코딩된 주소를 사용하기 때문이다.

URL 인코딩 (URL Encoding)

URL을 인코딩해야 하는 경우 https://www.urlencoder.org/ 등의 무료 서비스를 이용하거나 JavaScript에서 encodeURI (반대로 인코딩된 URL을 디코딩하는 경우는 decodeURI) 등을 쓸 수 있다.

JavaScript의 예)
var url = “https://ko.wikipedia.org/wiki/대한민국”;
var encoded = encodeURI(url);
var decoded = decodeURI(encoded);

console.log(encoded); // “https://ko.wikipedia.org/wiki/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD
console.log(decoded); // “https://ko.wikipedia.org/wiki/대한민국

다음의 표는 많이 사용하는 문자에 대한 인코딩 값이다.

문자 인코딩후 문자 인코딩후
공백(space) %20 ! %21
%22 # %23
$ %24 % %25
& %26 %27
( %28 ) %29

URL 정규화 (URL Normalization)

URL 정규화는 URL을 정형화된 형태로 변환하는 과정이다. 정규화 과정에서 동일한 웹 리소스를 나타내는 여러개의 URL들을 문법적으로 동일한 URL을 표현하는 것이다. 주로 검색 엔진에서 URL 정규화를 통해 중복되는 콘텐츠를 줄이는데 사용한다.

예를 들어, RFC 3986 표준에서는 다음과 같은 정규화를 한다.

절대 URL, 상대 URL

지금까지 이야기한 URL은 모두 절대 URL이다. URL에서 필수적으로 필요한 프로토콜, 호스트, 경로까지 모두 가지고 있다. 반면 문맥에 의존하는 상대 URL도 있다.

웹브라우저의 주소창에는 문맥이 없기 때문에 절대 URL을 써야한다. 그러나 HTML 페이지 안에서 어떤 리소스를 포함할 때는 호스트 페이지의 문맥안에서 상대 URL을 쓸 수 있다.

예를 들어, 다음의 URL은 절대 URL이다.
https://www.betterweb.or.kr/foo/index.html

위의 index.html 웹페이지의 내용에 다음의 앵커 태그가 있다고 가정하자.

<a href="bar.html">Relative foo</a>

bar.html은 상대 URL이고 절대 URL로 변환하면 https://www.betterweb.or.kr/foo/bar.html 이다. 다른 예를 보자.

<a href="../parent.html">Relative root</a>

../parent.html의 절대 URL은 https://www.betterweb.or.kr/parent.html 이다.

텍스트 부분식별자 (Text Fragment)

텍스트 부분식별자는 URL 부분식별자에 텍스트 스니펫을 지정하는 기능이다. 웹브라우저가 텍스트 부분식별자가 포함된 URL로 이동할 경우 문서의 해당 텍스트로 자동으로 이동하고 강조하는 기능이다. 텍스트 부분식별자는 W3C의 WCIG그룹에서 제안(https://wicg.github.io/scroll-to-text-fragment/)하였고 Chrome은 버전 80부터 기능을 지원한다.

사용방법은 간단하다. URL의 # 문자(부분식별자 영역) 다음에 :~:text= 을 추가하고 강조할 문자열을 지정하면 된다.

#:~:text=문자열

예를 들어, 다음은 BTS 위키피디어 URL에 “most tweeted-about celebrities”를 텍스트 부분식별자로 추가한 것이다. 링크를 클릭하면 웹브라우저는 해당 부분으로 스크롤하고 매칭되는문자열을 강조하여 보여줄 것이다.

https://en.wikipedia.org/wiki/BTS#:~:text=most%20tweeted-about%20celebrities

쉼표를 이용하여 영역을 지정할 수도 있다.

#:~:text=시작문자열,종료문자열

https://en.wikipedia.org/wiki/BTS#:~:text=stands%20for,scouts

URL 사용시 주의할 점

타이포스쿼팅Typosquatting

인터넷 사용자들이 웹사이트 주소를 잘못 입력하는 실수를 예상하여 원본주소와 유사한 도메인을 미리 등록하는 행위. URL 하이재킹(hijacking)이라고도 한다.

예를 들어, google.com 대신 gooogle.com (‘o’가 세개다)을 입력할 것을 예상하여 gooogle.com 도메인을 선점하고 마치 원본 사이트인것처럼 조작하여 멀웨어를 심거나 사용자 정보를 요구하여 가로채기도 한다. 물론, 구글은 타이포스쿼팅을 예방하기 위해 gooogle.com을 포함하여 비슷한 도메인을 모두 소유하고 있다.

비슷한 도메인을 선점하는 것 외에도 SSL을 적용하여 사용자에게 실제 사이트라는 신호를 줄 수도 있다. SSL이 적용되지 않은 사이트(https)는 웹브라우저에서 위험하다고 경고를 해준다.

클린 URL (Clean URL)

클린 URL은 일반 사용자들도 쉽게 의미를 파악할 수 있고 검색 엔진에 친화적인 URL이다. 웹서버에서 정보를 관리하는 내부 구현방식과 분리되어 있고 웹사이트에서 제공하는 정보의 개념적 구조를 잘 반영한다. 따라서, 사용자가 URL이 지정하는 리소스가 무엇인지 쉽게 파악할 수 있다. 또, 논리적으로 정리된 구조를 따르므로 검색 엔진 최적화에도 좋다.

클린 URL은 example.php, example.asp 처럼 내부 구현 방식, 사용자에게 의미없는 내부 데이터베이스 식별자, 세션 ID 등을 포함하지 않는 등 서버 구현 및 사용자 환경에 따라 바뀌지 않는 URL이다.

예를 들면 (O)표한 URL이 클린 URL이다.
https://betterweb.or.kr/index.php?page=name (X)
https://betterweb.or.kr/name (O)
https://betterweb.or.kr/cgi-bin/feed.cgi?feed=news&frm=rss (X)
https://betterweb.or.kr/news.rss (O)
https://betterweb.or.kr/index.php?mod=profiles&id=193 (X)
https://betterweb.or.kr/profiles/193 (O)
https://betterweb.or.kr/blog?article_id=10023 (X)
https://betterweb.or.kr/blog/서치_콘솔 (O)

URL 단축 서비스 (TinyURL, Bitly)

이메일이나 트위터에 URL을 추가할때 긴 문자열 때문에 불편했던 적이 있는가? URL 단축 서비스는 긴 URL을 짧게 만들어주는 서비스이다. 케빈 길벗슨이라는 웹개발자가 2002년에 뉴스그룹에 글을 올릴 때 URL을 단축시키려고 TinyURL이라는 서비스를 만들면서 시작되었다. 이후 비슷한 서비스가 100여개 이상 나왔고 Bitly와 트위터 서비스인 t.co 등이 많이 쓰이고 있다.

TinyURL은 tinyurl.com에서 Bitly는 bit.ly에서 URL을 단축할 수 있다. 트위터는 긴 URL을 자동 단축해주며 단축된 URL은 t.co 도메인을 사용한다.

 

 

출처:https://www.betterweb.or.kr/blog/url%EC%9D%B4%EB%9E%80/

IP와 함께 PORT 번호에 대해서 들어보았을 것이다.

TCP 프로토콜을 살펴볼 때 전송하는 패킷에 PORT 번호에 대한 정보가 포함되어 있었는데 PORT 번호가 무엇인지 간단하게 살펴보자.

 

 

포트 번호는 해당 IP주소가 가리키는 PC에 접속할 수 있는 통로이다.

예시를 들자면, A 아파트 이름을 IP 주소라고 할 때 00동 00호로 상세한 집 주소를 나타내는 것과 같은 역할을 하는게 PORT 번호라고 생각하면 쉬울 것 같다.

포트는 0번부터 65535번까지 있는데, 하나의 PC로 연결을 할때 포트 번호에 따라 6만 가지 이상으로 구분할 수 있다.

 

보통 0~1023번 포트는 잘 알려진 포트로 이미 사용되고 있거나, 상징성이 있기 때문에 해당 프로세스가 아닌 경우에는 다른 포트 번호를 사용하는게 일반적이다.

잘 알려진 포트의 예시는 아래와 같다.

 

 

 

이미 사용중인 포트는 중복해서 사용될 수 없으므로 포트 번호를 지정할 때 해당 포트가 사용중인지 확인이 필요하다.

출처:https://javacoding.tistory.com/163

+ Recent posts